On 31 October 2013 22:52, Nicolas Cellier < [email protected]> wrote:
> 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 ;) > > ah, don't worry, i am myself sometimes like to think in such mode: 'what if...' 'it would be nice to try .. ' but certainly when its about addind/changing something in existing system (not just experiment), my main rule is to see how new idea could help to simplify the system, in terms of less code, cleaner design and less effort to implement. What i see in proposed one is straightly opposite to that. There's an infinite ways how you can draw a line on white board (and which tools you using to do that).. but i doubt you can invent something simpler and easier than using pen and own hand. > > > 2013/10/31 Igor Stasenko <[email protected]> > >> >> >> >> On 31 October 2013 22:37, Nicolas Cellier < >> [email protected]> 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 <[email protected]> >>> >>>> >>>> >>>> >>>> On 31 October 2013 08:25, Tudor Girba <[email protected]> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> On 2013-10-30, at 22:36, Igor Stasenko <[email protected]> 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. >> > > -- Best regards, Igor Stasenko.
