[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
|