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.

Personally, I see no huge benefit in using traits, except for documenting an abstract interface that clients should use as an extension point. Especially if subclassing is no option ... such as when adding a new protocol to, for example, the Morph class.

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.

Eventually, it depends on what you are going to achieve. I think that most projects will do fine without traits. Yet, traits can help you add a little bit more structure to your class tree. That is, if one is not willing to invest the effort in keeping the vocabulary of protocols/selectors consistent across classes and packages. :-)

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

Best,
Marcel
Am 20.02.2022 21:57:07 schrieb Lauren P <drurowin at gmail.com>:
Hi List,

What is the current status of Traits? Core functionality works, but there's no Browser support for classes built using traits, so it's actually slightly more confusing to use them rather than pure subclassing.

Also... what's the difference between #requirement and #explicitRequirement? The comment is... unhelpful...

>From learning to use them they seem helpful, but lack of Browser support meant having to dig through message lists to learn the definition and use templates, and then classes that are built from multiple traits leaves a sense of "where did I define this?" when you notice a message needs changed.

Is the package worth learning and adding Browser support for? or is there another design pattern List recommends?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220221/2169beb4/attachment.html>