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 <[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. >
