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 <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

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 <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.