Split Capabilities: Making Capabilities Scale

[Bill Frantz]

At 01:12 AM 7/26/00 -0700, Mark S. Miller wrote:
>I love this example.  However, Alan's objection that "increment" is a more 
>informative message name than "do" still applies so far.  First, I'd like to 
>make clear that my example was not intended as an example of good 
>programming style, but a demonstration of a case that can occur in any of 
>the capability systems under discussion.  Programmers cannot be forced to 
>give their programs meaningful message names.
>
>Second, the price of useful and valid runtime polymorphism is often just 
>such opaqueness.  An actual Java example:  Let's say both Norm's garage 
>entrance agent and garage exit agent record their events by pressing a 
>java.awt.Button, which was parameterized with a 
>java.awt.event.ActionListener.  When such a button is pressed, it invokes 
>the "actionPerformed" method of its ActionListener.  The ActionListener in 
>the Button pressed by the entrance agent responds by causing the count to be 
>incremented, but there's no reason for the Button to know this!
>
>Alternatively, one could have given the Button an object whose increment 
>behavior was named "increment" rather than "actionPerformed".  We would then 
>have needed to tell the Button the name of the method to invoke. I won't 
>argue about which style is better.  Both are plausible, and all capability 
>systems allow both to be coded, so we must give our systems a semantics 
>adequate to account for both.  I believe we could apply AWT to von Braun 
>with exactly the same results.

The choice of "actionPerformed" for all buttons has proven, at least to me,
to be a code maintenance nightmare.  As a maintenance programmer, your job
is to make change to a program, to fix a bug or implement a new feature, as
quickly and cheaply as possible.  In general you have not had time to read
and understand the whole program, which may be more than a million lines.
If the method name is "increment", you can grep the source for it, and
quickly narrow down the possible callers of that method.  If the name is
"actionPerformed", grepping the source results in hits on every button in
the system.  Then you have to perform a flow analysis to determine which
calls to that method have the object of interest.  Add tracing back thru a
few more "generic" method names, and general storage objects, and you have
a major investigation for what could have been a simple search.

Cheers - Bill