Re: General semantics

From: Nilone <>
Date: Fri, 21 May 2010 10:29:15 -0700 (PDT)
Message-ID: <>

On May 21, 3:12 pm, Erwin <> wrote:
> On 21 mei, 12:41, Nilone <> wrote:
> > 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.
> This is only true of read-only operators. Update operators are not
> relations/functions, and read operators with side-effects are "still a
> bit more" than just the relation/function on the arguments that
> determines the return value.
> If your aim is to "better understand OOP, and/or why it has the
> problems it has", then you can't narrow down the discussion to just
> read-only operators.

We must include the host system in the model. During execution, the DBMS / VM would derive the new state of the object from its variables and methods, and update the tuple(s) that represent it in the relvar(s) that describe the run-time state of the program.

> (a) There are probably hundreds of distinct ways to find
> correspondences between this class and relational concepts. A tuple
> of degree three with the attributes all being of type 'Man' and named
> 'Erwin', 'Nilone' and 'Bob', respectively, is one of them. And what
> about this : a relation is a set. Where is the set in your class ?

The class defines the set. You can see the members right there. In general, however, classes designate sets and subsets implicitly. Classes with public constructor functions (and some classes without them) define unbounded sets. However, I see it as one of the weaknesses of OOP that I can't query the set of all instances of a class. I could use a static private List or Dictionary to keep track of instances, but that would interfere with the GC reclaiming the object automatically.

> How can I intersect that set with another one ?

Please don't ask me to map from the relational model to OOP. I can't do so in general, since the RM has greater expressive power than OOP. The greater system can describe the lesser, but not the other way around.

I could write functions to determine intersections in specific cases, but your question illustrates a general weakness of OOP. Although OOP languages can't easily or generally query the objects in the memory of programs, I still think a relational interpretation of the constructs and mechanisms of OOP provide the best possible understanding of it.

> (b) The fact that a certain class can be fabricated that may seem to
> resemble a relation, does not warrant the conclusion that relation
> corresponds to class (and vice-versa), in general.

All OOP classes describe set-like relations over a domain of objects. I see no general relationship in the opposite direction. Perhaps I used 'correspond' incorrectly, I had in mind a unidirectional relationship. I took care to write that OOP classes 'correspond to' relations, and not vice-versa. If I messed up the terminology again, I apologize.

> (c) Wouldn't you agree that "static Man Erwin" is the declaration of a
> variable named 'Erwin' which' type is 'Man' (making abstraction here
> of the issue about pointers) ? Wouldn't you agree that " = new Man()"
> is an assignment of a value of type Man (once again making abstraction
> of the issue of 'pointer to Man') to that newly declared variable ?
> Wouldn't you agree that all of this very very strongly points toward
> 'Man' being a _type_ ?

I don't disagree with you, but I don't see the need for the term 'type' yet. I imagine "Man Erwin" declares a relvar with a maximum cardinality of 1, from the symbol Erwin to an element in the domain of the Man class. A 'null value' corresponds to the empty relation. "= new Man()" creates a new object in the domain of the class and updates the relvar. I can imagine other implementations, e.g. a binary relation for (symbol, class) and a relvar for (symbol, class, value).

> Yes, the RM is sufficiently complete to also be able to describe the
> entire state history of a running program.

Good, some common ground at last.

> > Therefore, there must exist a mapping from OOP to RM (I don't
> > think anyone could invert that mapping, though).
> I disagree with "therefore". I do not see what kind of axiom makes
> this a necessary consequence of the foregoing.

Would you agree that the RM can describe the entire possible state space of any program?

> It should be a well-known fact that no single
> relational structure is ever "THE" single unique possible solution to
> any given modeling problem.

I see, I used 'map' incorrectly. I had in mind that for every OO model, there exists at least one corresponding RM model. Would you agree with that?

> It feels to me like you're seriously mixing up distinct levels here.

The possibility always exists. I sometimes experience stubborn misconceptions and flights of fancy. I'll try to keep my nuttiness reasonable and well-mannered, and I appreciate any time and effort you spend to read and respond to me. Received on Fri May 21 2010 - 19:29:15 CEST

Original text of this message