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