Re: Issues with the logical consistency of The Third Manifesto

"Alfredo Novoa" <anovoa_at_ncs.es> wrote in message news:hdvhp0p5sa5r9hg0uthia57s38upg7nqpk_at_4ax.com...
> On Sat, 13 Nov 2004 15:32:44 GMT, "Marshall Spight" <mspight_at_dnai.com>
> wrote:
>
> >Well, I skimmed it; it was very wordy. Any critique of D&D's
> >"First Great Bluder" is okay in my book; their whole idea
> >is weak.
>
> IMO the idea is trivially true: types are types and not variables. But
> the First Great Blunder is a rare mistake.
>
> People don't identify classes with relations, people ignore and reject
> all modern data management theory. They often design that kind of
> classes because they want to manage the data from the applications.
> They never think about relations nor they know what relations are.

I tend to agree.

> Tuples are objects, relations are objects, classes are objects,
> variables are objects, operators are objects,

Agreed.

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

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

I disagree here.

> What does "the possibility of joining tables and having the proper
> 'class' materialize to handle it" means?
>
> He does not understand it because it is very bad expressed. There is
> nothing valuable or specific to the OO there.

Really? I thought this was one of the best comments the poster had. 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.

Marshall Received on Tue Nov 16 2004 - 03:58:23 CET