[Pharo-dev] Losing instance variable addition
nicolas.cellier.aka.nice at gmail.com
Thu Oct 31 13:30:47 EDT 2013
Unless initialization is lazy (and you arrange for avoiding/detecting
2013/10/31 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
> And you're going to bump into slot initialization order...
> 2013/10/31 Stéphane Ducasse <stephane.ducasse at inria.fr>
>> On Oct 30, 2013, at 10:54 PM, Camillo Bruni <camillobruni at gmail.com>
>> > On 2013-10-30, at 22:36, Igor Stasenko <siguctua at 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
>> >> 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
>> 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
>> Now the real question is not shape is how you garantee that it is well
>> Because you do not want to extend initialize because it does not work
>> Now with slot we can attach initializers to them and then we can get it
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev