On Thu, 28 Mar 2019, H. Hirzel wrote:

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

I meant Traits being used in practice.
Why am I asking this?
1. I always considered the idea of stateless Traits too weak to be useful. 
I proposed class mixing instead about 10 years ago, which IMO could be 
simpler and cleaner, because there would be no need to introduce a new 
kind of Behavior. But implementing that would be lots of work.
2. I've never seen them being used for anything that justified their 
existence.

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

That's what people used to say, but that's not true. Even in Pharo, where 
Traits were fully supported (with the same capabilities we have now in 
Squeak), they were only used because of the heavy push from the dictators. 
Once they found out the shortcomings of the idea of stateless traits, they 
replaced the implementation altogether with TraitsV2 - aka stateful 
traits.

>
> 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 shouldn't affect the current discussion about Traits, should it?

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

Did he? I must have missed 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.

It's not. Even some of the most basic things are incomplete. It only 
works because there's only one environment at a time. Moving forward would 
require system-wide changes.

Levente

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