Hi Mira:
 
>From mira@ccs.neu.edu Wed Nov 12 14:55:47 1997
>Cc: dem@ccs.neu.edu, gregor@parc.xerox.com, lopez@parc.xerox.com
>
>> If we call c an object, most people would be confused
>> and would think that c would exist at the same run-time as aPoint.
>> It is better to call c a coordinator description than an object.
>> The way Gregor and Crista put it, the point objects and the  
>> coordination objects are at a different level.
>>
>> Gregor made a point regarding what is interesting.
>> The fact that a coordinator is an object is not
>> interesting and should not be mentioned unnecessarily.
>> Indeed it confuses people who learn about AOP.
>
>I definitevely agree that the fact that coordination
>desciptions are objects should remain transparent for the
>user.  To my understanding, the point here is that
>conceptually ``c'' is a description entity -- a class
>metaobject if you want -- and not a run-time (or base) object.
>``c'' describes how the coordination aspect of run-time objects
>like the Point-object should be dealt with.
>The fact that ``c'' actually exists as an object is an implementation
>detail -- has to do with the particular way chosen in the current
>implementation to put  together components and the coordination aspect. As
>such it should remain transparent for the user.
>
>Is that a valid point of view?

I agree with your point of view except that in my world descriptions
and objects are tightly linked. Whenever I see a description, I see an
underlying class dictionary and an object. Whether those objects are relevant
at run-time, I consider an implementation detail, which matches what you
said.

>
>-- Mira
>

-- Karl