[squeak-dev] Re: Unload Traits script

Klaus D. Witzel klaus.witzel at cobss.com
Mon May 12 18:54:54 UTC 2008


On Mon, 12 May 2008 19:39:32 +0200, Andreas Raab wrote:

> Klaus D. Witzel wrote:
>> Interesting. What would be class Metatrait about (you do new new to  
>> it), other than for the browser's convenience? Would it make possible  
>> to apply the same traits to a) the instance side of class A and b) the  
>> class side of class B?
>
> Purely convenience. By having the class-side trait being represented as  
> the class of the instance trait, the browser doesn't need to be aware of  
> it. Not necessarily the most obvious solution but it keeps changes in  
> other places very minimal.

Yes, right.

> Your idea about applying traits is certainly possible but relationship  
> between traits and classes is already questionable as far as I am  
> concerned. For example, traits without a class trait can be applied to  
> meta classes; traits with class traits can not be applied meta classes;  
> but once an instance trait is applied to a metaclass one can still add a  
> method to its class trait etc. So I'm not in favour of making that any  
> more complex than it absolutely has to be; in fact, I'd be in favor of  
> abandoning the ability to apply instance traits to metaclasses  
> altogether for clarity.

It is perhaps possible to go one step further (or go back, for that  
matter) and have no instance traits and no class traits, but just traits  
(subclass of ClassDescription, instVar 'users'). It can be applied to  
either side of some class, since the whole machinery has no requirement  
other than #traitComposition (as far as I've seen). Wouldn't that make the  
exercise less complex and more clear, or am I missing something.

There may even be quite different compositions required for both sides of  
a class. As an example consider making Traits (incl. their tests ;) for  
the 5.3 Fundamental Protocols of ANSI Smalltalk 1997. This looks to be  
impossible with dualistic traits.

/Klaus

> Cheers,
>    - Andreas
>
>>> The extension points to the existing kernel are
>>> few (and could be made fewer) and loading and unloading would be  
>>> trivial
>>> with just a tiny bit more work.
>>>
>>> In any case, this is not a complete implementation but rather an
>>> illustration that the current implementation isn't the only way traits
>>> can be implemented in Squeak and that an alternative can be small,
>>> loadable, and easy to understand.
>>>
>>> Cheers,
>>>    - Andreas
>>
>
>
>




More information about the Squeak-dev mailing list