[cap-talk] How do you define composite?

[David Hopwood]

Pierre THIERRY wrote:
> Scribit David Hopwood dies 16/02/2007 hora 17:29:
> 
>>"Object" in object-based programming languages always means an atomic
>>object. This was the terminology [..] consistently with that meaning
>>in every object-based programming language since, AFAIK.
> 
> Is there anything that is not an atomic object in the programming
> language context?

In a pure object-based system (whether it is a language or OS), the
system only directly implements [atomic] objects. Composites/abstractions
are what we use to *describe* the collective functionality of sets of
[atomic] objects.

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

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.

Switching back to my suggested terminology, objects and abstractions appear
at different levels of modelling of the system. An abstraction is
*implemented by* one or more objects. An abstraction *is not the same thing as*
the objects that implement it.

So in your example, we can describe the system as having the following
kinds of abstraction:

 - each int-abstraction is primitive, implemented by an object of type int.
   [The distinction between primitive values and objects in some languages
   is not important here.]

 - each Foo-abstraction is implemented by an object of class Foo, and two
   objects of type int.

 - each Bar-abstraction is implemented by an object of class Bar, two
   objects of class Foo, and four objects of type int.

Note that we can say "Foo-abstraction" and "Bar-abstraction" without ambiguity
because Foo and Bar respectively are their only facet classes (assuming
that 'quux' and 'quuux' are not facets). We might even loosely call instances
of these abstractions "Foos" and "Bars", but that should be strenuously
avoided when trying to explain the *concept* of abstractions. For an
abstraction with multiple facets, we'd have to give it a name that reflects
its overall functionality.

If we wanted to only partially decompose a Bar-abstraction into subabstractions,
rather than fully decomposing it into objects, we'd describe it as being composed
of two Foo-abstractions.

[Aside: see how "abstraction" fits better than "composite", especially
for 'int'?]

>>"Object" in access control terminology means an entity on which it is
>>possible to perform primitive operation(s) that are subject to access
>>control. This is not a composite: a composite with multiple facets
>>would have to be modelled as multiple objects in the access control
>>sense.
> 
> But when I'm reasoning about access to a driver, I consider the driver
> to be an object [in Charles Landau's sense], although it could well be
> a composite object.

This is missing the point. The access control is applied to each visible
facet, separately. That is, each facet must be assigned a separate column
in the access matrix (because a subject might have different permissions
to the different facets). "Object" in the access control sense must
therefore correspond to a facet of the driver (which is an object in my
or MarkM's sense), rather than to the driver abstraction.

The access control matrix fails to model the system in sufficient detail
to account for the fact that having permission to one facet may imply
authority to affect the behaviour of the other facets; i.e. it is not a
good model for reasoning about multi-object abstractions.

> That's precisely why there are abstraction boundaries: I don't have to
> know if it's atomic or composite in the inside, for me it's an object,
> whatever it's internals.
> 
> As a matter of implementation, a composite object will always be an
> atomic object whose behaviour depends on atomic objects it can
> communicate to.

No, it never will be. A *facet* of a composite/abstraction will always be
an [atomic] object whose behaviour depends on [atomic] objects it can
communicate to.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>