Unless initialization is lazy (and you arrange for avoiding/detecting circular dependency)
2013/10/31 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> > And you're going to bump into slot initialization order... > > > 2013/10/31 Stéphane Ducasse <stephane.duca...@inria.fr> > >> >> On Oct 30, 2013, at 10:54 PM, Camillo Bruni <camillobr...@gmail.com> >> wrote: >> >> > >> > On 2013-10-30, at 22:36, Igor Stasenko <siguc...@gmail.com> 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 >> >> >> >
