Hehe, no problem, because any method from SecondThirdPartyRandomExtensio
nPackage would know which z slot to use.
Or if you insist on uniqueness, you can invent decorators like well known
languages ;)
It could get more complex if a FourthThirdPartyExtension would like to
extend the second extension further and directly access this specific z
slot ;)
2013/10/31 Igor Stasenko <siguc...@gmail.com>
>
>
>
> On 31 October 2013 08:25, Tudor Girba <tu...@tudorgirba.com> wrote:
>
>> I completely disagree with this point of view :).
>>
>> We should assume an open world, not a close one. From this point of view,
>> any part of the system should be extensible by anyone. In most other
>> languages I know, it is not even possible to extend easily a class with new
>> functionality. In Pharo we can, and we know it is a powerful mechanism. It
>> is not the responsibility of the base class to know what extensions are out
>> there and protect against them. Just like with subclassing, It is in the
>> responsibility of the extender.
>>
>> We should be able to do the same with state as well. Without this
>> mechanism, we are forced to put in place clunky dictionary-based mechanism
>> to support state extension. Essentially, any white-box framework does that.
>> For example, Morphic does that, FAMIX and Roassal do that, too (and yes,
>> this is not a bad thing).
>>
>> We need this mechanism in the environment, and if I understand Slots
>> correctly, now we have first class support for it. This also means that
>> overrides will be easier to deal with, too. Of course, overrides can induce
>> headaches from time to time, but we should treat these headaches with
>> proper tools, not by forbidding the world to extend.
>>
>> And if we are at it, we should also be able to extend a class with
>> Traits, too.
>>
>> it is doable, and easily, as others saying nothing prevents you from
> saying
> SomeClass addInstvarNames: 'foo'
>
> but the problems in not extending per se, but how you manage it at source
> level?
>
> Like you said, we now having slots.. so
> then how you think a class definition may look like if some class has
> extension slots
> defined by other package?
>
> Object subclass: #Point
> slots: {
> x, y -> Kernel-Classes
> z -> ThirdPartyRandomExtensionPackage
> z -> SecondThirdPartyRandomExtensionPackage
> z -> ThirdThirdPartyRandomExtensionPackage
> }
>
> i am not against being open.
> i am against being open to opening can of worms ;)
>
> (Apart from completely inadequate proportion between effort to implement
> such feature and supporting it in many tools (MC etc) comparing to the
> actual/current need of having it).
>
> Clearly, there is no limits in complexity where we can go in attempt to
> describe our systems with metadata up to tiniest level of detail.
> Except from some real-world ones:
> - implementation effort
> - ease of learn & use
> - and at last.. sanity :)
>
> Cheers,
>> Doru
>>
>>
>>
>>
>> On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni
>> <camillobr...@gmail.com>wrote:
>>
>>>
>>> On 2013-10-30, at 22:36, Igor Stasenko <siguc...@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
>>>
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
