[Pharo-dev] Losing instance variable addition

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Oct 31 13:37:28 EDT 2013


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 at gmail.com>

> 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/1094d71b/attachment-0002.html>


More information about the Pharo-dev mailing list