Re: Issues with the logical consistency of The Third Manifesto

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:4199ee3b.7913171_at_news.wanadoo.es...
> 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.

Actually, an object is always a value, and simultaneously always a variable (assuming it has any mutable fields.) It is also always a conceptual entity. But this is such triviality that I've never seen anyone bother to mention it. No one is *confusing* values and variables; an object is both, and which one we are talking about is, most of time, immediately obvious.

There *is* an issue with the difference between equality and identity in OOP, but this is fairly easily mastered by beginners.

> 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.

Okay.

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

Yes, but this doesn't matter. There are specific models associated with each specific OOPL, and they are quite well documented down to the last detail. There are also substantial commonalities among the different models.

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

The binary method issue? This is again a fairly unimportant issue.

> They know that pointer based programming is painful and primitive.

Here I will agree that they are ahead of the OO crowd, which is still quite wrapped up in pointers.

> 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.

Hmmm. I will not disagree. But I will point out that there are some quite coherent authors on OOP; Fowler for example, or see also Joshua Bloch's brilliant "Effective Java."

> >> 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.

Does they have methods specific to the specific join? I think that is what the guy was referring to. Ideally this would be done dynamically, not via code generation.

Marshall Received on Tue Nov 16 2004 - 18:11:42 CET