Yes, exactly. The complexity explodes.

Moreover an if construct should be replaced with a polymorphic  
construct, even here:
	return comp returnWrapperNode

and then the method returnWrapperNode has to be implemented on  
ContainerNode and ComponentNode.

Ah, but wait, this Java language they are using does not support  
class extensions, so you have to go for the non-OO solution or know  
all your classes and wrappers up-front and add the necessary  
'returnWrapperNode' methods :-( :-(

It shows how choices in your packaging/deployment format in the end  
turn out to drive the design of your programs. Even though you can  
shoot yourself in the foot with the Smalltalk deployment approach  
(that allows method and class additions and redefintions ), *it does  
not drive my design*. This, to me, is a very clear advantage.


On 03 Mar 2007, at 3 March/18:08, Klaus D. Witzel wrote:

> Hi Alex,
>
> I read the CaesarJ tutorial until it said
>
>  if(comp instanceof Container)
>   {returnContainerNode((Container)comp);}
>  else{returnComponentNode(comp);}
>
> which is about "wrappers are selected depending on the dynamic type  
> of the wrappee".
>
> In this simple example there are just containers and components. I  
> fear that in more complex situations the actual number of "if (x  
> instanceof Y)" becomes unmanageable :(
>
> /Klaus
>
>
> On Sat, 03 Mar 2007 17:36:03 +0100, Alexandre Bergel wrote:
>
>>>> I don't think it would be conceptually hard to do something similar
>>>> in Smalltalk if you were to have class lookup work similarly to
>>>> method lookup but along namespace hierarchies.
>>
>> No, this is not difficult to achieve. This is even called "virtual  
>> classes", or "virtual type".
>> Want some example of existing systems? CaesarJ [1], Keris [2],  
>> gbeta [3],
>>
>> [1] http://caesarj.org/
>> [2] Author's web page: http://zenger.org/research.html
>> [3] http://www.daimi.au.dk/~eernst/gbeta/ and particularly http:// 
>> www.daimi.au.dk/~eernst/papers/fampol.ps
>> [4] Thesis of William Cook, http://www.cs.utexas.edu/~wcook/papers/ 
>> thesis/cook89.pdf , most interesting for our purpose is Section  
>> 3.5 page 27.
>>
>>> I'm working on that.
>>>
>>> Now... if I make a stable, usable, clean and largely
>>> backwards-compatible solution, will people integrate it into Squeak?
>>> It would be a very large, dare I say revolutionary change.
>>
>> Should be trivial to implement in Squeak. Some issue arise when  
>> implementing this in a static type language (http:// 
>> www.daimi.au.dk/~eernst/papers/tr-pb577.pdf), however this is not  
>> an issue for squeak.
>>
>> Where you might have some problems is to achieve a complete  
>> integration with the tools...
>>
>>
>>
>>>> The other thing that
>>>> would make extension safe is a copy on write semantic with class
>>>> wherein extensions to classes that are not local to your namespace
>>>> result in a new class with the same name in your namespace being
>>>> created that derives from the class in the parent namespace.  Thus,
>>>> your mods are kept local to your context.  It does make class  
>>>> binding
>>>> harder as class names have to be resolved dynamically in the  
>>>> methods
>>>> that reference them.
>>>
>>> That's harder.
>>
>> This is a hard problem. I spend 4 years on it (http:// 
>> www.iam.unibe.ch/~scg/Archive/Papers/ 
>> Berg05aclassboxesJournal.pdf , feel free to skip the greek stuff  
>> if you're not comfortable with).
>>
>> I am interested in having virtual classes in Squeak.
>>
>> Cheers,
>> Alexandre
>
>
>