Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Monday, July 31, 2000 11:42 AM
> To: Karp, Alan
> Cc: 'Jonathan S. Shapiro'; 'Ralph Hartley'; e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 11:19 AM 7/31/00 , Karp, Alan wrote:
> > > From: Mark S. Miller [mailto:markm@caplet.com]
> > > ...  I believe we all earlier agreed with 
> > > this sentiment, as with Chinese tea prices.
> > > 
> >
> >I didn't intend to agree with your statement.  
> 
> And you proceed to disagree, I think.  But then you say
> 
> >... If that results in a change of the state of some object O2
> >whose state I'm unaware of, so be it.  I can't distinguish 
> changes in the
> >state of O2 from that of the private part of O1; hiding the 
> implementation
> >is good programming practice.  In particular, the programmer 
> of O1 is free
> >to move private state to O2 as long as O1's contract is 
> still honored.  I
> >think we're in big trouble if that's not the case.  So, if I 
> write a program
> >that lets you print a file, I don't care if the price of tea 
> in China is a
> >private variable in the printer object or in the state of 
> the China economy
> >object.
> 
> I'm sorry, but I can't distinguish this last paragraph from 
> agreement.  Are 
> you saying that the programmer requires total knowledge of the 
> implementation, or only knowledge of the contract?  I love 
> Ralph's example 
> of how the contract of an incr/decr service can hide possible state 
> transitions, and still be exactly the right info to write a von Braun 
> client.  If the von Braun programmer counts on any more 
> information than 
> this, such as fuller knowledge of these state transitions, he 
> will write a 
> broken client.
> 
> 
>          Cheers,
>          --MarkM
> 

I think my example quite clearly shows that I'm talking about contract
(interface), not implementation.  Isn't moving the price of tea from an
internal private variable to a part of the state of the China economy object
an implementation decision?

Physicists say, "Anything that is not forbidden is permitted.", but that's
not realistic in writing software.  How many different conditions am I going
to have to test before I get down to doing any useful work?  If von Braun
sees a contract with only a decrement operator, and he creates an instance
with an initial value of 10, should he be surprised to see the rocket not
launch after 10 decrements?  I say yes; the rest of the world says no.
You're all crazy; I'm the only one whose sane!  Case closed.  

Seriously, though, the problem is understanding the implications of the
legal state changes.  Of course, von Braun can write a countdown object that
will work properly even if there is an increment method he is unaware of.
I'm just contending that he's more likely to get his program right if he
knows that method exists.  

_________________________
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