The problem is that control version system just save text not text and meta data
because a package could have a class definition + in our case a instance
variable addition object
Now we just save text so this is why we are in trouble. Again this is a
text-oriented diff way of the world
and this is poor.
Stef
>
>
>
> 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.
