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

[David Hopwood]

David Hopwood wrote:
> Bill Frantz wrote:
> 
>>I have real problems with the term "composite" meaning a multi-faceted
>>state bundle.  Much of the problem comes from the fact that it violates
>>David's statement (slightly rewritten):
>>
>>>we should not be basing our terminology on the viewpoint of people who
>>>do try to understand concepts in terms of particular implementations.
>>
>>"Composite" only makes sense in systems which do not support method
>>availability sub-setting as part of the reference, and even worse, gives
>>a seriously wrong impression in systems which do support such
>>sub-setting.
> 
> I don't understand this argument at all. All object-capability systems
> allow interface subsetting (whether or not they support it primitively),
> and the "composite" concept makes perfect sense in such systems. The
> subsetted object is a new facet.

I could, however, understand an argument that said that for any system,
"composite" doesn't properly describe a collection of objects such that
one is obtained by subsetting the interface of another.

If that is your objection, then perhaps "abstraction" is a good alternative
to "composite":

 - it doesn't imply that an abstraction is necessarily built by composition
   (rather than subsetting or some other type of construction).

and, as I said before in
<http://www.eros-os.org/pipermail/cap-talk/2006-December/006700.html>:

 - it is easy to explain that an abstraction is a subjective way of describing
   an aggregation of objects. This is consistent with one of the existing
   commonly used senses of "abstraction".

 - "composite" suggests *more than one* object, i.e. that a single object is
   not a composite. This is not what we want: a single object should be just a
   special case (where there is one facet and no hidden objects). "Abstraction"
   does not have this problem.

 - an abstraction is both something that *can* be used as part of a larger
   abstraction, and that may be composed of smaller abstractions.

 - this usage is not inconsistent with the usage of "abstraction" [as a
   count noun] in mathematics, electronics, and other engineering fields
   besides software.

 - the existing term "abstraction boundary" makes sense in this context --
   it corresponds to the boundary between objects that are part of the
   abstraction and objects outside it. The facets of the abstraction can be
   considered to be "on" the boundary, and this makes a nice picture for use
   in visual explanations.

 - if it is necessary to distinguish this from some other kind of abstraction,
   then we can use "object abstraction" to disambiguate. In practice, most
   software abstractions in an object capability system will be object
   abstractions. So I no longer think that the term "abstraction" is too
   general.

OTOH,  it's quite possible that someone will come up with other objections to
"abstraction". We cannot keep thrashing around indefinitely for terms that
everyone is completely happy with. (Even if we reached a concensus that all
of the current frequent posters on cap-talk agreed to, someone else could join
the list or 'delurk' and start the argument all over again.)

The particular choice of terms is, IMHO, far less important than the principle
that the same term should not be used to refer to several distinct concepts in
the same subject domain. That's why I object so strongly to the suggestions to
use "object" for *both* of the concepts that MarkM's thesis calls "objects" and
"composites".

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