Taxonomy of Facets & Composites

[Tyler Close]

Shap wrote:
> > MarkM wrote
> > >
> > > At the "laws of physics" level, there are only objects,
> not facets or
> > > composites.  An object is a combination of state and behavior.
>
> I cannot recall if I responded to this, but I believe it is
> false. There is
> no "laws of physics" sense in which computational state
> must be bound in
> singleton fashion to an interface.

If there isn't, then the resulting system is not a capability system.

I believe Markm's sole purpose in establishing the "law of physics"
layer is to come up with names and definitions for the circles and
lines in the Granovetter diagram. This layer of abstraction must be
the "law of physics" layer, since actions that cannot be described by
composition of the Granovetter operator must not be possible in a
capability system.

In capability systems like E and Droplets, it is natural to call the
circles objects and the lines references, since that is what they are
implemented as. In these systems, the Granovetter operator is the "law
of physics" layer at both the theoretical and implementation levels.
EROS and some of the other capability systems being discussed have
different implementations. Unless you have discovered a more primitive
operator for capability systems, it must be possible to reason about
your implementation solely in terms of the abstractions defined by the
Granovetter operator.

It would be nice to have English descriptions of the circles and lines
in the Granovetter diagram that fully capture the constraints imposed
on the implementation, as well as making evident the flexibility that
the implementor has. The taxonomy that Markm seeks will likely be
found in a study of the ways in which the Granovetter operator can be
implemented. You and Alan have taken issue with the proposed names and
descriptions. Perhaps the exercise should be reversed. Can you
describe the Granovetter operator in a way that is accurate for your
implementation? Finding this description will be more difficult than
it was in the case of E and Droplets; however it must be possible,
since the described behaviour is intrinsic to a capability system.

> There is no reason to
> believe that one
> interface is more natural than two or three or N.
>
> The problem with MarkM's reasoning is that while the types
> of the interface
> may be closable by adding a fictitious "top" to the type
> lattice, in actual
> practice such a "top" rarely exists in the real system.

The word object should not be confused with the word Object. We are
not in any way talking about a type lattice. A particular object may
very well have N contracts that it implements and there are no
constraints on the relationships, if any, between these contracts.

We are talking about the dynamic structure and behaviour of a
capability system, not any static description of its component pieces.

Tyler


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com