Hi Stef,
On Thu, Oct 31, 2013 at 6:49 PM, Stéphane Ducasse <[email protected] > wrote: > > 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 :) > What is not the same? :) By "override" I meant the problem induced by two packages that define the same method, and that are being loaded at the same time. Cheers, Doru > > 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" > > > -- www.tudorgirba.com "Every thing has its own flow"
