Re: General semantics

On May 20, 10:51 pm, Erwin <e.sm..._at_myonline.be> wrote:

Thanks for the feedback. Let's see if I can explain and defend that argument.

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

Not at all. However, OOP languages are built on OIDs / references / pointers. Any relational description of OOP must include them.

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

Yes, of course.

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

My apologies, yes, the constructor always inserts a new tuple into the domain of the class and returns its reference. It works just like a SQL table with a hidden row number, and we can understand its problems by viewing it in relational terms.

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

I agree with the requirement.

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

We can describe deterministic methods as binary relations over the possible states of a set of variables. We can say that OOP classes embed these methods as RVAs in the class or subclass.

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

Like in SQL tables, virtual methods in OOP classes correspond to attributes with default values, which subclasses can overwrite. One source of confusion in OOP comes from the assumption of default behaviour, which can be overwritten by subclasses.

The mess of collection classes in OOP languages originate in the inability to query the extensions of classes. The lack of relational algebra leads to cursors / enumerators.

>
> 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".
>
> Now does such a thing correspond to "object class" ?  No, it doesn't.

Why not? I can write object classes that correspond to that relation. Here's one, somewhat unconventional, in C#:

class Man
{

    static Man Erwin = new Man();
    static Man Nilone = new Man();
    static Man Bob = new Man();

    private Man() { }
}

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

I would like to avoid the word type for now, please? I say an object class doesn't correspond to the heading of a relation, but to a subset of a relation with its associated heading.

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

I don't see it yet, but I do appreciate that you're trying to point it out to me.

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

Keith described the binding relation of a variable over time in the "On Formal IS-A definition" thread. AFAIK, we can express any mechanism of OOP in relational terms. OOP programs get compiled every day. Trivially, each compiler corresponds to its own model of OOP. However, class-based languages share many similarities, so we can generalize some. I believe any model can be described as a relational model. Therefore, there must exist a mapping from OOP to RM (I don't think anyone could invert that mapping, though). By viewing OOP in relational terms, I hope to understand it and learn how to work around its idiosyncrasies. I don't want to advocate OOP, and I hold no love for it, but I have to work with it. How am I to understand its problems if I refuse to look at it? Received on Fri May 21 2010 - 12:41:27 CEST