[Pharo-dev] Losing instance variable addition

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Oct 31 17:52:06 EDT 2013


I agree, on all you said.
But sometimes it's also interesting to push the concepts further and
explore their benefits/drawbacks before knowing exactly which problems they
will solve.
A researcher POV rather than an engineer one.
I'm an engineer, so I can play advocatus diaboli ;)


2013/10/31 Igor Stasenko <siguctua at gmail.com>

>
>
>
> On 31 October 2013 22:37, Nicolas Cellier <
> nicolas.cellier.aka.nice at 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 <siguctua at gmail.com>
>>
>>>
>>>
>>>
>>> On 31 October 2013 08:25, Tudor Girba <tudor at 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 <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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131031/d79a8990/attachment-0002.html>


More information about the Pharo-dev mailing list