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

[David Hopwood]

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.

> (CapOSes and language systems with fat pointers allow such
> sub-setting.  Vtable (and other) systems do not.)

There is no such thing as a "system with fat pointers" (unless the system
makes the use of fat pointers visible to applications, but if so then it's
not an object-capability system, since object capabilities are opaque).
Any use of fat pointers is an *implementation* choice.

Implementations that don't use fat pointers, whether they use v-tables or
not, certainly can support interface subsetting. E-on-Java is such an
implementation (IIUC), and E allows the following:

  # untested
  def makeSubsetFacet(underlying, verbs) :any {
      def subsetFacet {
          match [verb, args] {
              if (!verbs.contains(verb)) throw("verb not allowed")
              return E.call(underlying, verb, args)
          }
      }
      return subsetFacet
  }

More generally, I have no idea why you keep making a distinction between
systems based on whether an implementation might use fat pointers and/or
vtables. In a well-designed system, such things are completely invisible
to applications. The same system design can have implementations that
use fat pointers or not, and that use v-tables or any other dynamic
dispatch implementation (independently).

> The terminology I like better is multi-faceted object, or just object,
> but I am open to other suggestions.  I might even tolerate
> "multi-faceted state bundle", but I suspect most would not.  Note that
> in systems with method availability sub-setting in references, the
> (single) object has all the methods that are described by a union of all
> its facet's methods, so we do maintain the definition of object as state
> and the methods that act upon it.
> 
> Building a composite of many objects to achieve this goal is an
> implementation work-around for systems that do not have this level of
> expressiveness natively,

No. The obj-cap model treats such cases as composites regardless of how
they are implemented. If there were a primitive with the same functionality
as makeSubsetFacet above, it would make no difference.

> and might not be necessary in systems where
> references of an interface type can not be cast to the implementing
> class.

The base object-capability model is untyped. If a system has additional
type-based restrictions, that doesn't by itself prevent the obj-cap model
from being used to describe it, but the type-based restrictions will not
be modelled unless by some extension to the model.

> In these systems, we might be better off calling the front-end
> objects, "method availability sub-setting" objects.

They are interface subsetting *facets*.

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