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