[cap-talk] Objects and Facets

[Norman Hardy]

On Aug 7, 2006, at 4:39 PM, Mark Miller wrote:

> On 8/7/06, Charles Landau <clandau at macslab.com> wrote:
>> This sounds just like the "no facet" view I described. It's great to
>> know we're in agreement on this.
>
>>> For descriptive purposes, we often want to aggregate several  
>>> objects into one
>>> composite. Such aggregation is purely subjective.
>>
>> We are in complete agreement.
>
> Wonderful!
>
>
>>
>>> In KeyKOS, a natural
>>> descriptive aggregate for many purposes is the process (domain)  
>>> together with
>>> all the keys which designate the root node of that process (all  
>>> start keys,
>>> domain key, node key).
>>
>> Now I'm confused. A composite is an aggregation of objects, but keys
>> are not objects, so why do you include those keys in the composite? I
>> think you mean, all the objects designated by those keys.
>
> Yes.
>
>
>> In fact I think it would be correct to just say that the composite is
>> all the objects designated by those keys, and omit the phrase "the
>> process (domain) together with" above. The process alone isn't a
>> well-defined object; it would work as a name for this composite.
>
> Agreed.
>
>
>>> Given some descriptive composite, those objects within
>>> the composite which are potentially designatable from outside the  
>>> composite
>>> are facets of the composite.
>>
>> For example, a start key with a particular facet id, which is outside
>> the composite, designates an object in the composite and is a facet
>> of the composite.
>
> Yes.
>
>
>> Unfortunately, we need some better terminology for describing
>> composites, which is why many people are using the term "object" when
>> they mean composite.
>
> David's suggestion of "component" isn't bad. I haven't thought of
> anything better.
>
Component sounds like a part of something else, What is a component  
part of?

I don't understand where you propose to use "facet" in the new scheme  
of things.
If you say that a facet is an object that holds a capability to the  
underlying object, you are over-specifying the implementation.
Perhaps your terminology keeps you from being necessarily  
noncommittal about implementation.
My definition of the up-down counter said nothing about the nature of  
the returned keys, except for the meaning of their invocation.
If there is a one-to-one correspondence between capabilities of  
objects, as you propose, then most contexts can use "capability" but  
I agree you need two terms conceptually.
I think we agree on ontology but not terminology.

Category                     ---    proposed name
Designators; states of slots   ---  key,  capability
Things designated  ---   (I like facet; you like object)
Site of state  ---   (I like object, you like composite(?))

It feels to me like we have somehow shifted terminology left by one  
(or right) and thereby have lost use of a perfectly good word with  
fine connotations.
I can say an object bundles behavior(s) and state. What will you say?

> -- 
> Text by me above is hereby placed in the public domain
>
>     Cheers,
>     --MarkM
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk