On 21 janv. 2014, at 19:07, Sebastian Sastre <[email protected]> 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 > > http://jameso.be/2014/01/19/lisp.html > > It would be super awesome if we never ever ever have those problems > > > > > > > > On Jan 21, 2014, at 3:41 PM, Esteban A. Maringolo <[email protected]> > 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 <[email protected]> >> >> On 21 janv. 2014, at 17:53, Stephan Eggermont <[email protected]> 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. >> >> >
