[squeak-dev] Re: Unload Traits script (response to edgar)

Trygve Reenskaug trygver at ifi.uio.no
Wed May 14 17:46:57 UTC 2008


On 14.05.2008 16:41, Andreas Raab wrote:
> itsme213 wrote:
>> "Andreas Raab" <andreas.raab at gmx.de> wrote in
>>> Trygve Reenskaug wrote:
>>>> A role is played by an object at run time. This object can be an 
>>>> instance of any class that implements its trait. So the trait is 
>>>> tied to a fundamental abstraction that is on the same level as the 
>>>> class.
>>> Interesting. But aren't you describing interfaces?
>>
>> The role itself is better compared to a variable than to an interface.
>
> Do you mean something like (for example) the "bounds role" or the 
> "fill role" for Morphs? If not, then I don't understand what roles 
> mean in this context.
>
>> The  corresponding trait can provide an interface definition, as well 
>> as an implementation that refers to other related roles.
>
> It can but if it's to provide the implementation you end up with 
> complexity explosion again since the dependencies will be implemented 
> by other traits, which will require even more traits etc. By the end 
> of the day there will only be a handful of suitable compositions of 
> traits that result in something usable (which is exactly what we've 
> seen in other applications of traits) and these few compositions 
> usually can be better expressed without traits.
>
> The idea that having traits require other traits for their 
> implementation leads to flexibility is flawed. Flexibility results 
> from having abstract interfaces which allow (and sometimes require) 
> the implementor of the interface to go only by the observable 
> structure and not rely on anything that just happens to be part of the 
> implementation. Traits have been constantly used the other way around 
> by requiring the users of one trait also to pull in all the garbage 
> that comes along with the implementation of that trait.
>
>> I think Trygve figured out a way to extend the compiler so that the 
>> method bodies (typically in traits, I expect) can use distinguished 
>> "Role variables", which the compiler translated into a dynamic lookup 
>> query.
>
> That will be interesting to see. Although, I can't help but wonder: 
> Why not simply bundle up these "role variables" and their 
> corresponding behaviors and call 'em "object"? In which case you'd 
> represent them by a class, having access to all the state in one 
> place, being able to encapsulate its behavior etc.
>
> Cheers,
>   - Andreas
>
>
Why not indeed?  I've better get my act together so that we can get a 
solid foundation for a constructive discussion, haven't I?
Cheers
--Trygve

-- 

Trygve Reenskaug       mailto: trygver at ifi.uio.no

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080514/d1affeb8/attachment.htm


More information about the Squeak-dev mailing list