[PRL] may be

Karl Lieberherr lieber at ccs.neu.edu
Thu Nov 6 08:21:46 EST 2003


-----Original Message-----
From: Mitchell Wand [mailto:wand at ccs.neu.edu]
Sent: Wednesday, November 05, 2003 3:13 PM
To: lieber at ccs.neu.edu
Cc: PRL
Subject: [PRL] may be

>>>>> On Wed, 5 Nov 2003 14:32:04 -0500, "Karl Lieberherr"
<lieber at ccs.neu.edu> said:

KL> Hi Matthias:

KL> I did not have a chance to respond in person. Here is my fix to
KL> the "may-be" formalization:

KL> A B-object may be contained in a C-object iff the traversal
specification
KL> [C,B] defines a non-empty set.

KL> The may-be relation is covered in my undergraduate class ((<=.C.=>)*.<=
KL> where . is relation composition). Maybe I misunderstood your statement
that
KL> the may-be relation is NOT easy to formalize.

This can't possibly be right, because the model of objects you mention
doesn't distinguish between association and aggregation (or
composition).

I talked about class graphs that have only is-a and aggregation edges.

And EA is fundamentally about aggregation:  it is inheritance down
aggregation links.

Will talked to David after the seminar, and concluded that may-be is a
parameter of the semantics.  By this he meant the following:

** The class graph includes must-contain, direct-subclass-of, and
   has-as-part edges (and maybe others).

** The language designer provides an algorithm for computing may-be
   from the relations in the class graph.

** The meaning of ACQUIRE is based on this (derived) may-be relation.

So the programmer does not have to specify the may-be relation when he
writes down the class graph.

Whether a particular object graph is legal wrt a particular class
graph has nothing to do with may-be.  That's different from what I was
saying after the talk.

At least that's my understanding of what Will told me.

That is consistent with my understanding, except that the traversal-based
may-be definition that I mentioned (based on [A,B]) is a very good default
may-be relation directly defined by the class graph.
But I can easily see that the programmer writes acquisition strategies
(using traversal specifications) that define the scope of acquisition she
wants.
-- Karl

--Mitch





More information about the PRL mailing list