[squeak-dev] Traits (was Re: Universal Composition and modules)

Ronald Spengler ron.spengler at gmail.com
Thu Dec 3 20:23:02 UTC 2009


Whoops, that paper just makes mention. Here's the detailed report
regarding collections:

http://scg.unibe.ch/archive/papers/Blac03aTraitsHierarchy.pdf

On Thu, Dec 3, 2009 at 12:21 PM, Ronald Spengler <ron.spengler at gmail.com> wrote:
> Igor: +1. I think the technical plane is in part a function of the
> social plane. What Traits needs more than anything else is more
> documentation. Research papers are great, but some tutorials would be
> useful to newbies like me.
>
> FYI the paper in question mentioning the collections refactoring is here:
>
> http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf
>
> And the rest of the documentation is here:
>
> http://scg.unibe.ch/research/traits
>
> On Thu, Dec 3, 2009 at 11:39 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>> 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.
>>
>>
>
>
>
> --
> Ron
>



-- 
Ron



More information about the Squeak-dev mailing list