I'm with Doru here, we already have the capability of extend completely the system (not just to extend methods). Even if can be dangerous, that's a choice of the user. Our tools should empower the features of the language, not restrict them.
On Oct 31, 2013, at 7:49 AM, Camillo Bruni <camillobr...@gmail.com> wrote: > > On 2013-10-31, at 09:55, Clément Bera <bera.clem...@gmail.com> wrote: > >> Basically here we discuss how to introduce in Pharo stateful class extension >> and stateful traits. I like these features a lot because it means I would be >> able to reuse the same class differently depending on the context and the >> surrounding classes. But if we overuse that we will definitely go into >> chaos. Martin tried in Mist and he concluded that he should have class >> composition instead of stateful traits / class extension. > > right, using stateful traits a quite a bit different than directly adding > inst vars ;). > This way you can easily ensure that the added variable is only visible to the > new code and hence you do not run into the override limbo. Now that we have > first-class slots, doing these things gets much easier (note that stateful > traits was an example implementation in the slot paper). > > I think the resulting "mess", which we already have with normal traits, is > the lack of tools. For instances, pharo didn't properly respect traits in the > IDE for years with the result that most of the trait methods slowly vanished.
