[Pharo-dev] Losing instance variable addition

Nicolas Cellier 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
circular dependency)


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>
>> wrote:
>>
>> >
>> > 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
>> 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131031/1f2466f4/attachment-0002.html>


More information about the Pharo-dev mailing list