sebastian Doing is difficult. Do you think that we did not reimplemented traits from scratch already once. May be we are just not smart enough or may be the problem is more complex that people think it is. You can ask around me. I’m not happy with traits but I’m not happy with single inheritance too and I do not like multiple inheritance either. So :)
I can tell you tales on huge macros in lisp that generate pages of macros and a company wanted to hire me to add concepts in the language to remove these hug macros. the grass is always greener elsewhere, no? If we want to really improve the system we should accept that it may not be a simple easy path. Stef On 21 Jan 2014, at 19:07, Sebastian Sastre <sebast...@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 > > 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 <emaring...@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.ter...@gmail.com> >> >> On 21 janv. 2014, at 17:53, Stephan Eggermont <step...@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. >> >> >
