[cap-talk] "Composite", was "Same" key
david.nospam.hopwood at blueyonder.co.uk
Sat Feb 10 19:26:21 CST 2007
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
> 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
- 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
- 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
- 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
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
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the cap-talk