[squeak-dev] The Inbox: TraitsTests-pre.19.mcz

H. Hirzel hannes.hirzel at gmail.com
Thu Mar 28 20:35:06 UTC 2019

On 3/28/19, tim Rowledge <tim at rowledge.org> wrote:
>> On 2019-03-28, at 10:43 AM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> On Thu, 28 Mar 2019, patrick.rein at hpi.uni-potsdam.de wrote:
>>> The test documents the (currently not working) workflow for removing a
>>> trait from a class by simply removing the "uses:" line from the class
>>> definition. To make this work, we would have to make the
>>> Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
>>> method aware of traits. The method would have to reset the trait
>>> composition as
>>> Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category:
>>> currently does. Potentially, the change could also be embedded deeper in
>>> the class creation code to avoid that duplication and make the other
>>> class creation methods more robust.
>>> I am hesitant, as I am aware that traits have been prevented from being
>>> integrated more deeply so far. At the same time, the described missing
>>> workflow has already led users to struggle with using traits in the first
>>> place. So as they are part of the system I would rather improve their
>>> usability. Any other oppinions?
>> What are the current use cases for traits?

To implement object roles, for example.

>> Just asking, because I'm not aware of any. And if that's the case in
>> general, then we should remove them.
>> Tool support is still incomplete after 10+ years.

Traits are not used because they are not properly supported,

And the creators (of
>> Traits in general) have moved on 10+ years ago as well (and have abandoned
>> Traits in this form).

Other issues are also still open after 10 years.

> That's almost exactly what i've been saying for years now; they were (are)
> an interesting idea but never got properly supported in any tools and so
> never got to be used in any meaningful way (that I've ever heard of - I'd
> love to find I'm wrong) but they do 'cost' us a non-zero amount of work to
> maintain and keep in the system.

Patrick stepped forward to do it.

> Kinda like Environments; sounds like a
> really good idea, we have a load of stuff in the image that has something to
> do with them but nothing that makes any easily apparent case for using them.
> And in my current day-job with VW I am coming to deeply, deeply, despise the
> implementation therein.

We are talking about Squeak here. And the  environments
implementation is a different issue. The work done so far is useful.

> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Living proof that nature does not abhor a vacuum.

More information about the Squeak-dev mailing list