Meaning of object

[Jonathan S. Shapiro]

Per Alan, I have changed the subject line...

We have stumbled into an issue that has been rattling around my head for
some time without resolution. As a side effect of being brainwashed by Norm
et al., I have become unhappy with the notion and lexicon of "objects". As
the author of the first book on reusable object-oriented software
construction I find this considerably ironic.

MarkM writes:

> However, what's an "object"?  If we take seriously the
> conventional slogan that "An object is a combination of state and
behavior",
> then the object-state shared by a set of facets is not an object, it is
only
> state.

This is indeed the traditional definition of "object", and I have come to
the conclusion that it is flawed. There is nothing wrong with the
definition, but it doesn't capture what we want in the capability context,
and I suggest that it may never have been what we wanted in the OO context.
I believe that this definition encapsulates a "think-o" (by analogy to a
typo) that is a side-effect of static typing.

I must preface what follows with the caveat that it is all half-baked. It
has been trying to gel unsuccessfully in my head for some time.

First off, this definition doesn't capture current practices. The
introduction of  a "const" qualifier fatally compromises this definition, as
does the notion of private and/or protected members/methods. I claim that
the current practice of OO interfaces is where we have state and a *set* of
interfaces, and these interfaces can be ordered in a lattice. For example, a
read-only interface is a strict subset of a read-write interface. That is,
we can rationally induce a complete partial order (CPO) on the interfaces.

I object to this model because it unnecessarily imposes a CPO, and that this
imposition deprives us of an empirically valuable dimension of engineering
flexibility: I'm also unconvinced that the lattice assumption survives
examination once contravariance are considered. It does adequately cover
inheritance.

The distinguishing evolution from objects to capabilities is the elimination
of the CPO restriction.

In EROS, there is no lattice that can capture all of the variations on Node
capabilities. In particular, start capabilities convey authorities that are
*not* conveyed by domain capabilities. We can artificially synthesize a
"top" for the lattice, but the type system isn't really a hierarchy.

I hypothesize that the security relationships between the interfaces can
only be formally understood when the lattice is (possibly synthetically)
closable. Come to think of it, verifying this is an interesting theoretical
research problem.

That being said, the non-lattice structure becomes important when we are
trying to understand the behavior of user-implemented objects. A piece of
code can implement many, arbitrary interfaces on internal state. These
interfaces need not export even the same conceptual object. In the absence
of a common logical object no lattice structure on the interfaces makes
sense.

Thus, the object-oriented case is a subset of the capability-oriented case.
All object structures can be encapsulated in capability-based interfaces,
but not all capability interface configurations can be encapsulated within
the OO framework.

    There is no essential reason to associate a *single*
    distinguished "behavior" with a particular bit of state.

In short, I argue that facet-oriented programming is strictly more powerful
than object-orented programming, and that perhaps we should devote some
attention to the distinction.

> Jonathan, besides our terminological differences, I think there may also
be
> a semantic difference between our descriptions.  You speak of a capability
> as combining state/object (what I call state & you call object) with a
*set*
> of access-rights rather than a *mapping* from order codes to
access-rights.

I have spoken in this way, but of late I have tried to avoid this. More
recently, I have spoken of capabilities as combining state with an
interface. In a dynamic type system, the static interface implements message
dispatch. In a static type system, the interface notion holds directly.

In the wake of our offline conversations, I think that this confusion
reflects the fact that I am contemplating static type systems at the moment.


shap