On Oct 31, 2013, at 8:25 AM, Tudor Girba <[email protected]> wrote:
> 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. + 1 the runtime should be smart enough to recalculate objects shape. > 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. This is not the same :) > > 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"
