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.


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.


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,

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