2009/12/3 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 2009/12/3 Stéphane Rollandin <lecteur at zogotounga.net>
>>>
>>> What problem are you trying to solve?
>>
>> well, I have several issues that would be nicely addressed by Traits. the
>> problem I would like to see solved is that of usability of Traits in Squeak.
>> I believe Traits are currently not really usable, by lack of system support
>> (tools, etc.)
>>
>>> For whatever reason, nobody seems to care enough about this to do the
>>> tools integration work.
>>
>> I guess the reason is that the Traits implementors have moved to another
>> project, where they may or may not have better tool support in the near or
>> far future.
>>
>>> It is hard to imagine that adding a different
>>> (and probably incompatible) implementation of traits would cause the
>>> tools integration to happen any faster.
>>
>> I'm not talking about adding an incompatible implementation, I just
>> recalled that Andreas once said here that the current implementation is
>> deeply flawed, overly complicated and could be *replaced* by a much better
>> one. I may be wrong here, which is why I asked.
>>
>> Stef
>
> One issue with the current traits implementation is the cost/benefit ratio.
>  Because it isn't used except in its own implementation it doesn't pay its
> way.  It introduces lots of complexity and doesn't return functionality
> because it isn't used in the places where it could be.  The most important
> place is the collection hierarchy where a trait-based implementation should
> in theory produce a much more flexible composable library.  See Bill
> Cook's "Interfaces and specifications for the
>
> Smalltalk-80 collection classes.", from "OOPSLA ’92,".  I'm ignorant of the
> history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits
> to the Smalltalk Collection Classes" so I don't know why we ended up with
> just traits applied to the traits implementation and lost traits applied to
> the collection hierarchy.  I'd like to know why.  My gut is that it might
> have broken too much older stuff.  If this is right then IMO this is another
> strong argument for producing small kernels that can load modules.  One
> could imagine a kernel that included traits applied to the collections into
> which one could load packages.  The traits collections kernel and the old
> collections kernel could exist side-by-side and we could compare, provide
> migration tools for subclasses of old collections, etc.
>

I agree that currently Traits is not widely adopted and used among
developers (be it Collections or something else).
I seen couple of times, people saying that it would be cool to use
traits for rewriting the Collections classes, but to my knowledge,
nobody started with it yet.
But i don't agree that there is a bad cost/benefit ratio. I think that
problem lies more in social plane (widely adopting & accepting new
idea(s)) and only then in technical plane - i.e. maturity level (both
implementation and tools).
I think that traits has many things to offer to developers, in
addition to smalltalk 'standard' as we know it.

> Another issue with traits is instance variable access.  Newspeak throws away
> direct inst var access and only uses accessors so its mixins can add
> instance variables.  So in some sense the Squeak traits implementation isn't
> radical enough.  But throwing away inst var accessors really feels like a
> new language, or at least a new system, because it impacts so many things:
> at the implementation level the ClassBuilder can and should behave
> differently, the bytecode set should be different, a JIT should use
> copy-down, etc; at the class library level one can factor things very
> differently.
>

There are some quite radical ideas concerning traits, which definitely
will feel like a new language:
- with introduction of stateful traits, one could completely eliminate
the class inheritance,
by replacing it with trait composition.

> To grapple with the kind of language evolution implied by traits and
> Newspeak I think we should be working on package-level refactoring that aims
> at being able to move packages between different languages.  It would be
> great to back-port Vassili's native GUI from Newspeak.  It would be great to
> migrate  Andrew, Nathanael and Stéphane's collection classes to Newspeak (or
> as the Newspeak team is trying to migrate Strongtalk's collection classes).
>  But doing this manually is IMO insane because its labour-intensive and
> error-prone.  Yes, parts of any migration may require intervention in the
> form of hand-crafted rules for special cases but it can't be a first-order
> process.
>
> best,
>
> speaking in ignorance of Squeak's recent evolution,
>

ignorance is a blessing to learn something new, or a curse, if one
don't wants to learn :)

> Eliot
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.