[e-lang] Capability Terminology related to O-O (was Terminology and soap box)

[Jed at Webstart]

At 09:56 AM 8/10/2006, Mark S. Miller wrote:
>Karp, Alan H wrote:
> > Ian G wrote:
> >> Here's my soap box response:  capabilities are indistinguishable
> >> from the concepts (not the practice) of object orientation.
> >
> > I agree for object capabilities, but there are other possibilities,
>
>I agree so far.
>
> > e.g., c-lists.
>
>Huh? All object-capability systems are c-list systems. (Though not all c-list
>systems are object-capability systems.)

I'm a little puzzled by this exchange also.  I agree with Ian's original
statement - though I'm not sure why he distinguished the practice.

Let's see if I can do a stepwise refinement:

1.  A "capability" is a permission token.

Any disagreement here?  So far that just means that if an active object
(process - generally an executing program) has a 'capability' then it can
do something that it couldn't otherwise do.  We say that the permission
granted by a 'capability' can be exercised by the process (active object) by
"invoking" the capability.  In any execution environment there will be limits
placed on what the executing program has the authority to do (the recursive
closure of its permissions).  Execution environments where possession of
a permission token is one way to obtain permissions are "capability"
environments/systems - to whatever extent.  So far so good?

2.  Capabilities can be communicated.

I.e. from one active object to another.  For me this is the critical element
of the capability model - which for is (for me) synonymous with the "object
capability" model (expecting some disagreement there).  If there are important
finer distinctions that can lead to some sort of effective taxonomy 
of capability
systems I'd like to understand them enough to describe them in terms as
simple as these.  The communication of a capability is the act of delegation.

One can of course ask how a capability can be communicated.  Since
communicating at all is something that requires a permission, in an
environment (pure capability) in which all permissions are granted by 
capabilities
a capability could only be communicated by invoking some (possibly other)
capability.

I feel that limiting the term "capability" to pure capability models is
too restrictive.  Being so restrictive would mean, for example, that
we couldn't use the term "capability" to refer to YURLs or widewords.
We would need some other term for communicable permission tokens
in "impure" systems.  I believe the capability term can be meaningfully
applied to such systems.  I hope others agree.  If we accept that
generalization, then in some systems there may be other means for
communicating capabilities (e.g. email of YURLs), though the fewer
permissions there are that aren't granted by capabilities of course the
more pure the capability model.

I'm not sure how this "purity" of capability model maps to the
O-O language world.  Perhaps others can help.  I think it amounts
to requiring that access to an object can only happen through
possession of a reference to some method on that object.

3.  An 'object' is that to which a capability grants a permission.

I don't see how an object can be less or more.  I believe that this
definition fits with that of the O-O model.  There it might be a
reference (to a method) that provides access to the object.  I
agree with Ian in that I don't see any meaningful distinction.  For
me a reference to a method (others may wish to correct my O-O
language terminology where I'm somewhat weak) is identical to
a capability.  Such references can be communicated as arguments
where we can think of them as sharing "objects", but of course it
is access to the object (some permission to act on it - "invoke" it)
that is being conveyed (communicated) by any such argument.

Unite!  (shortened soap box stump).

--Jed http://www.webstart.com/jed/