[Pharo-dev] Losing instance variable addition

Igor Stasenko siguctua at gmail.com
Thu Oct 31 17:37:56 EDT 2013

On 31 October 2013 18:49, Stéphane Ducasse <stephane.ducasse at inria.fr>wrote:

> On Oct 31, 2013, at 8:25 AM, 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.
> + 1
> the runtime should be smart enough to recalculate objects shape.
> and run into conflict with each and every use of instance where it implies
that it has certain shape (or state) but not the other one.

IMO, extending original class is anti-modular. It is global, thus
by definition.

I would much more prefer instead of saying:

Package A is: {
  extends: Object withSlot: x


in scope of Package A {
  Object instances i creating has extra slot: x

because when you making extension to class globally visible,
while nobody else is aware of (because it comes only with your package you
just loaded), this brings nothing but just problems
on many different levels.

Aside there's much wiser path (imo), how you can 'extend' the state:
by either subclassing or delegation/wrapping/decoration, which helps to
clearly separate between what is yours and what is not.

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.
> This is not the same :)
> And if we are at it, we should also be able to extend a class with Traits,
> too.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131031/40e9441f/attachment-0002.html>

More information about the Pharo-dev mailing list