Re: Issues with the logical consistency of The Third Manifesto

On Tue, 16 Nov 2004 02:58:23 GMT, "Marshall Spight" <mspight_at_dnai.com> wrote:

>> > In any event, it's pretty
>> > clear that D&D don't really understand OOP;
>>
>> I disagree. IMO they understand OOP a lot better than the overwhelming
>> majority of the OO coders.
>
>I've seen no evidence that they understand it in any least way.

IMO TTM is an evidence.

They know that object sometimes means value, sometimes means variable, sometimes means conceptual entity, etc.

The know that methods are operators and that class sometimes means scalar type and sometimes means entity type.

They know how OO inheritance works and that it is more related to delegation than to subtyping.

They know that there is not a thing called "The OO Data Model".

They know that to bundle operators with a single type is not a good idea.

They know that pointer based programming is painful and primitive.

Etc.

>> The problem is that the principle of incoherence applies to the OOP.
>
>I disagree here.

I should say to an important part of the OOP authors like Ambler, Larman.

>> He does not understand it because it is very bad expressed. There is
>> nothing valuable or specific to the OO there.
>
>Really?

Really, it is horribly expressed.

>What does it mean? It seems obvious to me; but then, I've done
>a lot of application coding that talks to a dbms in OOPLs. It means
>that one would like to be able to have a lightweight way of having
>a class (alternatively: a set of methods) associated with the rows
>of a resultset, even if this resultset came from a join, so that one
>could directly go from a query to a set of objects.

I am using that kind of classes since my first database application.

In Delphi such class is called TDataSet, in VB I think that it was called RecordSet, in .NET there is a class called DataTable, in PowerBuilder there is a class called DataWindow, etc.

Regards Received on Tue Nov 16 2004 - 13:12:30 CET