[cap-talk] "Composite", was "Same" key

[Charles Landau]

Inheritance is a more telling pattern than abstraction. Consider the C++ code:

class Dog
{
   int i;
}

class Collie : private Dog
{
   int j;
   Dog * AsDog(void) {return (Dog *)this;}
}

Collie lassie;
Dog myDog = lassie->AsDog();

OO programmers would say: lassie is a single object, and myDog is 
another view of that object. (For example, to quote 
http://en.wikipedia.org/wiki/Object-oriented, "When *an* object .. 
inherits its traits from more than one ancestor class, ...".)

I would say: lassie and myDog are two facets of the same object, 
which is a composite object containing the atomic objects i, j, 
instance of Dog, and instance of Collie.

MarkM would say (because he is so much more precise than I): lassie 
is the name of a reference to an (atomic) object with the behavior of 
class Collie, and myDog is the name of a reference to a second 
(atomic) object with the behavior of class Dog. These two (atomic) 
objects, together with the two integer (atomic) objects to which they 
hold references, constitute a set of objects or a composite.

At 5:29 PM +0000 2/16/07, David Hopwood wrote:
>"Object" in object-based programming languages always means ...

Everyone says that an object is a combination of state and behavior, 
or data and code. But they mean different things by it.

At 1:11 AM +0000 2/17/07, David Hopwood wrote:
>As section 6.2 of MarkM's thesis says:
>
># Like an individual object, a composite is a combination of state 
>and behavior.

But MarkM goes on to say:

# ... but here we have an important difference.

In object-oriented programming, the code is thought of as a 
collection of methods, and there is usually another mechanism 
("member access control" in Ellis and Stroustrup) that determines 
which methods you are permitted to invoke via a given reference to 
the object. Because OO programmers do not think of this mechanism as 
part of the "code" of an object, they can say lassie is a single 
object with multiple views.

In MarkM's object (my atomic object), the data and code are the 
mutable and immutable parts, respectively, of everything that 
influences what happens when you invoke a specific reference to the 
object. The code thus includes the member access control mechanism. 
Thus lassie and myDog are different (atomic) objects because they 
have different code.

When MarkM says

# Like an individual object, a composite is a combination of state and behavior

he includes in the state and behavior everything that influences what 
happens when you invoke *any* of the references to the (atomic) 
objects that comprise the composite.

At 7:10 PM +0100 2/16/07, Pierre THIERRY wrote:
>The following Bar looks like a composite to me, although it would
>obviously be called object:
>
>class Foo
>{
>	int i, j;
>}
>
>class Bar
>{
>	Foo quux, quuux;
>}
>
>If Foo is considered atomic because it's called an object, then how
>could Bar be considered atomic too, as it gathers two atomic entities?

It is a mistake to think of an object of type Bar as *containing* 
other objects. It contains *references* to other atomic objects, 
which may have the same lifetime.

On the other hand, if you want to consider Bar, quux, and quuux 
together, then you have a composite object that contains quux and 
quuux. If you consider Bar, quux, quuux,, i, and j, then you have a 
different composite object.

At 11:14 PM +0000 2/16/07, David Hopwood wrote:
>This kind of confusion is another reason why I don't like Charles Landau's
>"atomic object" and "object" terms. That terminology encourages a category
>error by implying that an atomic object is a kind of object. It's actually
>a different kind of thing entirely.

If that bothers you, consider my "atomic object" to be a set 
containing exactly one of MarkM's objects, my "composite object" to 
be a set of more than one of MarkM's objects, and my "object" to be a 
set of one or more of MarkM's objects. Then atomic objects and 
composite objects are both kinds of objects.