On 31 Oct 2013, at 10:15, kilon alios <[email protected]> wrote:
> Wow so much work to add an instance variable ? > > In python is as simple as > > MyClass.newVariable = 30 > > I always assumed Pharo was very similar. The discussion is about source code management. Of course this is very easy in Pharo. > On Thu, Oct 31, 2013 at 10:55 AM, Clément Bera <[email protected]> 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. > > For now the common way to add extra instance variable is: you add an extra > instance variable named 'properties' in the main class which needs to be > committed on the other package, then in the class extension you initialize > this varable lazily to a dictionary, and to use extra instance variable, you > store/read them in the properties dictionary by overriding the getter/setter > method. You can look at the refactoring browser AST which is implemented like > that. This way is nice because it is easily optimizable by slots (even if we > have not done it yet) and you only add 1 instance variable to the main class > whereas you can add an infinite number of instance variables. > > Best, > > > 2013/10/31 Tudor Girba <[email protected]> > I completely disagree with this point of view :). > > We should assume an open world, not a close one. From this point of view, any > part of the system should be extensible by anyone. In most other languages I > know, it is not even possible to extend easily a class with new > functionality. In Pharo we can, and we know it is a powerful mechanism. It is > not the responsibility of the base class to know what extensions are out > there and protect against them. Just like with subclassing, It is in the > responsibility of the extender. > > We should be able to do the same with state as well. Without this mechanism, > we are forced to put in place clunky dictionary-based mechanism to support > state extension. Essentially, any white-box framework does that. For example, > Morphic does that, FAMIX and Roassal do that, too (and yes, this is not a bad > thing). > > We need this mechanism in the environment, and if I understand Slots > correctly, now we have first class support for it. This also means that > overrides will be easier to deal with, too. Of course, overrides can induce > headaches from time to time, but we should treat these headaches with proper > tools, not by forbidding the world to extend. > > And if we are at it, we should also be able to extend a class with Traits, > too. > > Cheers, > Doru > > > > > On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <[email protected]> > wrote: > > On 2013-10-30, at 22:36, Igor Stasenko <[email protected]> wrote: > > > I don't think there's something to fix. > > You cannot 'extend' classes belonging to other package in any other way > > than adding extension methods. > > Allowing extension of ivars or any other vars by foreign package > > is road to nowhere. > > > > I would not like if shape of my kernel classes depends on what packages i > > load > > or in what order i loaded them. > > To me it is clear that if one needs to add/remove/modify instance variables > > of some class, those changes should belong to the package containing that > > class, > > not some random package. > > Exactly, it would cause the same problem as we have with overrides in > monticello > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > >
