[M3devel] small design problem in ButtonVBT?

Mika Nystrom mika at async.caltech.edu
Wed Apr 1 19:33:01 CEST 2009


Seems a bit mysterious to me too but I wonder if it's not a way of
getting the benefits of multiple inheritance.  If you want method
m1 from one set of VBTs V and method m2 from another set W, you
can't inherit from both.  But if the methods are instead procedure
fields with the common supertype as the first argument, you can set
the fields of X, m1 := V.M1, m2 := W.m2, even though X is a subtype
of neither V nor W...

You can probably use a design pattern to get something similar
without using procedure fields, but that would involve introducing
new types.

    Mika 

"Rodney M. Bates" writes:
>hendrik at topoi.pooq.com wrote:
>> The BottonVBT contains an action, which is a procedure rather than a 
>> method. b This makes it awkward to subclass ButtonVBT becaue the action 
>> will still expect its first parameter to be a ButtonVBT instead of 
>> belonging to the subclass, and an explicit downcast of some sort will be 
>> needed to acess the subclass's members.
>> 
>> The Trestle manual says this was a deliberate decision:
>> 
>> : The action procedure is a field rather than a method in order to allow 
>> : buttons with different action procedures to share their method suites.
>
>I don't understand the original reasoning.  If 'action' were a method, you
>could create different buttons with overrides for 'action' but not override
>any other method and get exactly the same set of shared methods among the
>buttons as in the original design.  What have I missed?
>
>> 
>> I, however, find it massively inconvenient because it mans I have to 
>> resort to downcasting or the very kludgey VBT.GetProp to access what 
>> should be just there.  I'd rather the action procedure was a method.  
>> 
>> But it should be possible to have the best of both worlds.  Have an 
>> action2 (better name wanted here) method that is available for 
>> overriding, and by default calls the procedure in the existing action. 
>> field.  That action2 method wounl then be called by Trestle wherever 
>> action is now called.
>> 
>> Does anyone see problems with this?
>> 
>> -- hendrik
>> 
>
>Rodney Bates



More information about the M3devel mailing list