And you're going to bump into slot initialization order...
2013/10/31 Stéphane Ducasse <[email protected]> > > On 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 > > Sorry but this is not the same as having overrides in Monticello. It is > the same as having class extensions! > So class extensions are powerful and we should get the same for instance > variables. > > Now the real question is not shape is how you garantee that it is well > initialized!!! > Because you do not want to extend initialize because it does not work > modularly. > Now with slot we can attach initializers to them and then we can get it > modular. > > Stef > > >
