On 31 October 2013 22:37, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:
> 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 ;)
>
> like i said, we can invent anything, put many workaround and/or
conflict-resolution
rules. The main question is it really worth it?
We can endlessly theorize, how to put such thing and what should be
done/changed,
but first i need a compelling reason, clearly showing the advantage of
having it.
So far, i can only see, that it will bring more problems than solve.
I am in favor of KISS, unless there is big and apparent wins in having
extra complexity.
> 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.
>>
>
>
--
Best regards,
Igor Stasenko.
