Hi Marcel,

On 2/21/22 07:47, Marcel Taeumel wrote:
> Hi Lauren --
> 
> Yes, as you already observed, the core functionality of traits work but tool support is limited. The use of traits is discouraged in Trunk but we want to keep it functional so that projects can use it.
> 
> How is the current tool support? If you change some code in a trait, all affected classes will be updated automatically. As for code exploration, besides the very basic senders/implementors, you can see the use of traits through the "hierarchy" browser scoped to a specific class or trait.
Tool support is inconsistent.  Traits are completely invisible to both
the hierarchy and protocol browsers, and the protocol browser cannot be
opened on a Trait.  They also do not report the message is implemented
via a trait.  The "inheritance" button is nonfunctional when browsing
the trait, but works when browsing a class that uses it.

The implementors browser shows that a trait implements some message, but
it also states the class the trait is used in implements it too.

The annotation shows as
"no timeStamp [...] in no change set"
when selecting a message inherited from a trait, which is the only way
you can tell you're looking at a trait implementation.

> Personally, I see no huge benefit in using traits, except for documenting an abstract interface that clients should use as an extension point.
This is how I'm seeing it, too.  It feels like a formalization of
message categories for extensions, but without the ease of fileIn/Out's
design.  I suspect it would work better if Trait WAS the fundamental
unit of organization for vocabularies and Class solely provided a
particular (private) implementation for some TraitComposition... but
ST-80 doesn't work like that.

> Especially if subclassing is no option ... such as when adding a new protocol to, for example, the Morph class.
Morph has had a lot of stuff added to it, much of which is simply
delegated.  If I understand correctly.  Traits would be useful for
reducing the amount of copy-pasting when copying the delegation code.

> Instead, I am in favor of keeping the vocabulary consistent for protocols and selectors -- even across classes and packages. Then it is easy to browse cross-cutting concerns. Well, the usual limitations of senders apply, which is that if your "term" is too simple (i.e., "open" or "delete"), you will get a lot of matches and then have to filter manually.
> 
> That is, if one is not willing to invest the effort in keeping the vocabulary of protocols/selectors consistent across classes and packages. :-)
As a newcomer to Smalltalk, selector name consistency is one of the
hardest things I've run into.  You can #at: a Dictionary but must #like:
a Set?  I'd say they are functionally equal (Set demands it compute the
key), but only Dictionary lets you look things up by the key.

In SUnit there is #assert:, #assert:equals:, and #should:raise:... The
vocabulary is consistent, but the argument order of #assert:equals: is
backwards.  There's also #at:put:, which seems unnatural compared to
#put:at:.

> My final two cents: I think that the use of traits tends to make the source code more complicated than it needs to be.
+1