Split Capabilities: Making Capabilities Scale

[Karp, Alan]

There seems to be some confusion as to what I'm talking about.  There is an
object O with some interface.  There are facets of O that represent
thinnings of that interface.  I agree there is no problem if the programmer
of some other object knows the interface to O.  If the programmer only knows
a facet of O, he may not be able to correctly code his object.

In your example, the programmer knows the interface to the garage, in
particular that it has an increment and a decrement method.  Could the
programmer have produced a correct garage object knowing only about the
decrement method?  Of course not.  Could two programmers, one knowing only
about the increment method and the other knowing only about the decrement
method produce an entrance object and an exit object, respectively, that
someone else could combine into a correct garage?  Perhaps, but it is likely
that the entrance and exit codes would be based on invalid assumptions.  For
example, the entrance object may assume that a garage that becomes empty is
an error because its programmer sees no way for the count to decrease.

I don't understand the comment about the square root of the radius.  There
is no difference between in behavior between taking the square root of the
radius or the diameter or the distance to Cleveland.  There is a difference
in behavior for numbers in general though, because they may be negative.
Hence a squareRootOfRadius() method needs no code to deal with negative
values, but a generic square root does.  Similarly, the user of such a
method need not worry about catching exceptions or dealing with imaginary
numbers.  I've used such tricks to optimize special functions used in
controlled environments.  At any rate, the routine doesn't have any
externally visible state, so it's not relevant to the present discussion.

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278


> -----Original Message-----
> From: Norman Hardy [mailto:norm@netcom.com]
> Sent: Wednesday, July 26, 2000 9:34 PM
> To: Karp, Alan; 'Ken Kahn'; Mark S. Miller
> Cc: 'Dan Bornstein'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 14:03 -0700 00/07/26, Karp, Alan wrote:
> >> Object-oriented
> >> programming is much
> >> less rich, much more narrow view of things. Adding facets
> >> helps a bit but
> >> why is this a good way to think about things?
> >>
> >> Best,
> >>
> >> -ken
> >>
> >
> >I don't really care if it's objects as long as I can reason about the
> >system.  Hidden side effects make reasoning difficult if not 
> impossible.  I
> >have a problem with facets in that interfaces not in the 
> facet appear to me
> >to be hidden side effects.  Objects, at least pure objects, 
> don't have side
> >effects, but any other such system would do as well for me.
> >
> 
> Someone must indeed be able to reason about the system, or at least
> the entire role of a particular counter. Take the case of the 
> garage counter.
> Probably the programmer of the code that requests a  counter instance
> knows the semantics of the counter including its three facets.
> He must also know all of the entrances and exits for the garage.
> He must destribute the incrementer facet to each entry agent
> and the decrement facet to each exit agent. These two agent
> populations are identical and each agent instance gets
> a thunk, which it invokes for each car. These agents or their
> programmers need not know whether the car is comming or going.
> 
> Someone must indeed reason about the big picture.
> But not all facet holders need to. Their contract merely requires
> them to invoke the thunk, once for each car.
> 
> It is good that the programmer of the sqrt routine need not understand
> that he is taking the quare root of a radius.
> Norman Hardy  <http://www.mediacity.com/~norm>
>