Re: General semantics

From: Erwin <e.smout_at_myonline.be>
Date: Thu, 20 May 2010 13:51:57 -0700 (PDT)
Message-ID: <8e542b6e-3854-43ca-a1af-50d47bdbd2aa_at_y21g2000vba.googlegroups.com>


On 20 mei, 12:27, Nilone <rea..._at_gmail.com> wrote:
>
> It sounds like the first one (http://c2.com/cgi/wiki?
> FirstGreatBlunder).
>
> I suspect now that OOP languages fail to properly distinguish the
> difference and relationship between intension and extension.

That is not a world-shocking observation. OOP languages mostly fail to properly make any relevant distinction (value/variable ?) whatsoever.

>  The specification of the OOP class defines a class-concept, which can be
> seen as a relation from an OID to a set of values (and possibly
> methods).

You seem to axiomatically assume that OIDs are a necessity, and that they _must_ exist.

Assertions of fact _can still be made_ if one does not have OIDs.

>  The constructor can be seen as a function selecting an
> object from the class domain.

No it cannot. If this were really true, then (using java as my particular OOP dialect) "new Integer(1) == new Integer(1)" would have to yield true.

Or one would have to leave the much desirable D&D requirement that "if x == y, then for all f : f(x) == f(y)".

> OOP interfaces correspond to relations
> between class-concepts, while abstract classes correspond to
> normalization.  Virtual methods include the signature of a method in
> the class-concept, while deferring the implementation to the class
> domain.

OOP Interfaces are declarations of which methods are to be available. Methods are (declarations of) operators. So OOP interfaces are (declarations of (sets of)) operators.

That is not a type of thing that can possibly "correspond to relations".

>  Hence, in a concrete class with virtual methods, we have both
> a class-concept and a default value for its domain.  Relations between
> class-concepts extend to the class domain, but don't include the
> default implementation.  Furthermore, the inability to enumerate the
> domain class of an OOP class leads to developers creating ad-hoc
> collections, and the failure to distinguish intension from extension
> and default values leads to faulty reasoning about all aspects of the
> system.

Sorry, sounds like gibberish to me.

Gathering nouns and verbs in the proper order does not a meaningful sentence make.

> So this deviates from Date's point of view, in that I equate object
> class with relation and not with domain or relvar.

Which is exactly one of the two blunders.

At one point, you referred to "extension" and "intension".

I may be stepping out of the bounds of my expertise here, but one thing I think I do understand is that a relation is the relationally "encoded" form of an extension of a logical predicate :

RELATION{TUPLE{Erwin}TUPLE{Nilone}TUPLE{Bob Badour}} corresponds to the extension of the predicate "x is a man" : "Erwin is a man and Nilone is a man and Bob Badour is a man".

(And now the nitpickers are going to say that there are more than three men in the world.)

Now does such a thing correspond to "object class" ? No, it doesn't. To the extent that it is even feasible/justifiable/warranted/... to imagine any kind of correspondence between the two, I would _always_, _unequivocally_ say that "object class" corresponds much more to "x is a man" than that it corresponds to any extension of that predicate.

The actual link I see is really obscure, which is why I said "to the extent that it is warranted to imagine any kind of correspondence" : object class corresponds to predicate, predicate corresponds to relvar, relvar has a (declared) (relation) type, therefore object class corresponds to (relation) type.

And just so you don't jump on this apparent distinction I might appear to be making between relation types and scalar types : both are just types, so what I said was intended to be interpreted as "object class corresponds to type".

> I hope my reasons are sufficient, if not, I await your criticism.

Sorry, but what you thought to be "reasons for your position", has, imo, to be dismissed on the grounds that they are "gibberish".

As a matter of fact, I happen to believe that trying to invent correspondences between "object model" and "relational model" is a futile waste of time, precisely because of the fact that the "object model" (which doesn't deserve to be labeled a "model" to boot, but never mind) fails to make the necessary proper distinctions between value and variable. Received on Thu May 20 2010 - 22:51:57 CEST

Original text of this message