On 21 janv. 2014, at 19:07, Sebastian Sastre <sebastian@flowingconcept.com> wrote:

We have to be careful about this.

I�m not saying traits doesn�t have its place but they are a solution to millions of non-problems

Note that this issue does not come from presence of traits but from the combinaison of two things:
- conflation of base-level (a.k.a. domain-level) and meta-level APIs: but it's like that since the invention of smalltalk (however it can be solve with a mirror-based architecture)
- recent unification of Class and Trait APIs that require classes to answer #users.
So similar problems were already present before this unification. The unification just added a few ones (including #users).
Basically, all selectors of Behavior, ClassDescription and Class should not be used as domain-level class-side methods: that makes around 500 "reserved" selectors.

Here is a post to reflect and learn from the problems of our neighbours, the lispers guys:

Lisp: more is less



It would be super awesome if we never ever ever have those problems







On Jan 21, 2014, at 3:41 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

This is where the "only 5 reserved keywords" stop being true :)

I've been bitten by similar things and ended up using my own selectors, sometimes with a prefix.

Regards!

Esteban A. Maringolo


2014/1/21 Camille Teruel <camille.teruel@gmail.com>

On 21 janv. 2014, at 17:53, Stephan Eggermont <stephan@stack.nl> wrote:

I tried loading Deltawerken in Pharo 3.0 and noticed
it is now impossible to load code where a class side method is defined named users.

DEUser class>>users
 ^self subclassResponsibility

Stephan

I guess it's a consequence of the unification of Class and Trait APIs. Now SomeClass users must answer an empty collection.
So you experience a name clash between Pharo meta-level and your domain :(
I still think it was a mistake too push that unification that far, i.e having classes responding to trait specific methods and vice-versa.