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
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.
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.
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.
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
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.
On 21 Jan 2014, at 23:56, Camille Teruel <camille.teruel@gmail.com> wrote:
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.
The question is what to do in general⦠itâs very hard to never change the API of Class⦠Marcus
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.
sure. Iâm okay with traits. Itâs kind of cool to have them. It just happens Iâve never needed them. The thing is about the names and too common and generic names high in the hierarchy is not so great. Is not a terrible thing either, just not great. Object>>name comes to mind On Jan 25, 2014, at 7:49 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
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.
Magritte description comes to mind... --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Jan 21, 2014 at 6: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.
Am 21.01.2014 um 20:08 schrieb phil@highoctane.be:
Magritte description comes to mind...
Itâs called magritteDescription since magritte 3. Norbert
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Jan 21, 2014 at 6: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.
I know, just another case --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Jan 21, 2014 at 9:13 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 21.01.2014 um 20:08 schrieb phil@highoctane.be:
Magritte description comes to mind...
Itâs called magritteDescription since magritte 3.
Norbert
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Jan 21, 2014 at 6: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.
On 21 janv. 2014, at 20:08, phil@highoctane.be wrote:
Magritte description comes to mind...
Why?
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Jan 21, 2014 at 6: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.
participants (8)
-
Camille Teruel -
Esteban A. Maringolo -
Marcus Denker -
Norbert Hartl -
Pharo4Stef -
phil＠highoctane.be -
Sebastian Sastre -
Stephan Eggermont