On Oct 31, 2013, at 6:37 PM, Nicolas Cellier <[email protected]> wrote:
> 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 ;) me too. Same for ClassVariables they should be totally self initializable without dependencies. Stef > > > 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 > > > > >
