Or, you infer the right order, for example from the AST of each initializer you should be able to get the dependency graph... My own preference goes to laziness ;)
2013/10/31 Nicolas Cellier <[email protected]> > Unless initialization is lazy (and you arrange for avoiding/detecting > circular dependency) > > > 2013/10/31 Nicolas Cellier <[email protected]> > >> 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 >>> >>> >>> >> >
