Smalltalk › Pharo › Pharo Smalltalk Developers

Losing instance variable addition

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

36 messages Options

Stéphane Ducasse

Losing instance variable addition

Hi guys

we are losing instance variables addition when loading a package.
Here is the example:

Gofer new
url: 'http://smalltalkhub.com/mc/gisela/Flamel/main';
version: 'Flamel-GiselaDecuzzi.94';
load

Normally RBProgramNode should have three new instance variables and not this is not the case.
Is it a known bug?

Stef

Stéphane Ducasse

Re: Losing instance variable addition

Apparently the problem is that gisela is adding instance variable to a class that is not in the Flamel package.
So it was working before but not anymore.

Stef

> Hi guys
>
> we are losing instance variables addition when loading a package.
> Here is the example:
>
> Gofer new
> url: 'http://smalltalkhub.com/mc/gisela/Flamel/main';
> version: 'Flamel-GiselaDecuzzi.94';
> load
>
> Normally RBProgramNode should have three new instance variables and not this is not the case.
> Is it a known bug?
>
> Stef

Stéphane Ducasse

Re: Losing instance variable addition

Ok in fact
Gisela forked the AST-Core package to be able to load a new version with the instance variables.
Because there is no way to say that a class definition modification is attached to a given package.

Stef

> Apparently the problem is that gisela is adding instance variable to a class that is not in the Flamel package.
> So it was working before but not anymore.
>
> Stef
>
>
>
>> Hi guys
>>
>> we are losing instance variables addition when loading a package.
>> Here is the example:
>>
>> Gofer new
>> url: 'http://smalltalkhub.com/mc/gisela/Flamel/main';
>> version: 'Flamel-GiselaDecuzzi.94';
>> load
>>
>> Normally RBProgramNode should have three new instance variables and not this is not the case.
>> Is it a known bug?
>>
>> Stef
>
>

Stéphane Ducasse

Re: Losing instance variable addition

Note that this is quite bad (and limit of MC) because it means that the people are forced to copy the package, do the modification
and publish and do that each time the mother package will change.

Stef

On Oct 30, 2013, at 7:15 PM, Stéphane Ducasse <[hidden email]> wrote:

> Ok in fact
> Gisela forked the AST-Core package to be able to load a new version with the instance variables.
> Because there is no way to say that a class definition modification is attached to a given package.
>
> Stef
>
>> Apparently the problem is that gisela is adding instance variable to a class that is not in the Flamel package.
>> So it was working before but not anymore.
>>
>> Stef
>>
>>
>>
>>> Hi guys
>>>
>>> we are losing instance variables addition when loading a package.
>>> Here is the example:
>>>
>>> Gofer new
>>> url: 'http://smalltalkhub.com/mc/gisela/Flamel/main';
>>> version: 'Flamel-GiselaDecuzzi.94';
>>> load
>>>
>>> Normally RBProgramNode should have three new instance variables and not this is not the case.
>>> Is it a known bug?
>>>
>>> Stef
>>
>>
>

Luc Fabresse

Re: Losing instance variable addition

Hi All,

I remember encountering the same problem somewhere and we fastly solved it using a preLoadDoit (I do not remember the exact name now) method of the ConfigurationOfOurProject in which we tested if the iv was there and if not added it.

Cheers,

#Luc

2013/10/30 Stéphane Ducasse <[hidden email]>

Note that this is quite bad (and limit of MC) because it means that the people are forced to copy the package, do the modification
and publish and do that each time the mother package will change.

Stef

On Oct 30, 2013, at 7:15 PM, Stéphane Ducasse <[hidden email]> wrote:

> Ok in fact
> Gisela forked the AST-Core package to be able to load a new version with the instance variables.
> Because there is no way to say that a class definition modification is attached to a given package.
>
> Stef
>
>> Apparently the problem is that gisela is adding instance variable to a class that is not in the Flamel package.
>> So it was working before but not anymore.
>>
>> Stef
>>
>>
>>
>>> Hi guys
>>>
>>> we are losing instance variables addition when loading a package.
>>> Here is the example:
>>>
>>> Gofer new
>>> url: 'http://smalltalkhub.com/mc/gisela/Flamel/main';
>>> version: 'Flamel-GiselaDecuzzi.94';
>>> load
>>>
>>> Normally RBProgramNode should have three new instance variables and not this is not the case.
>>> Is it a known bug?
>>>
>>> Stef
>>
>>
>

Igor Stasenko

Re: Losing instance variable addition

In reply to this post by Stéphane Ducasse

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.

On 30 October 2013 19:15, Stéphane Ducasse <[hidden email]> wrote:

Ok in fact
Gisela forked the AST-Core package to be able to load a new version with the instance variables.
Because there is no way to say that a class definition modification is attached to a given package.

Stef

> Apparently the problem is that gisela is adding instance variable to a class that is not in the Flamel package.
> So it was working before but not anymore.
>
> Stef
>
>
>
>> Hi guys
>>
>> we are losing instance variables addition when loading a package.
>> Here is the example:
>>
>> Gofer new
>> url: 'http://smalltalkhub.com/mc/gisela/Flamel/main';
>> version: 'Flamel-GiselaDecuzzi.94';
>> load
>>
>> Normally RBProgramNode should have three new instance variables and not this is not the case.
>> Is it a known bug?
>>
>> Stef
>
>

--
Best regards,
Igor Stasenko.

Camillo Bruni-3

Re: Losing instance variable addition

On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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

signature.asc (457 bytes) Download Attachment

Tudor Girba-2

Re: Losing instance variable addition

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.

Cheers,

Doru

On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <[hidden email]> wrote:

On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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"

Clément Béra

Re: Losing instance variable addition

Basically here we discuss how to introduce in Pharo stateful class extension and stateful traits. I like these features a lot because it means I would be able to reuse the same class differently depending on the context and the surrounding classes. But if we overuse that we will definitely go into chaos. Martin tried in Mist and he concluded that he should have class composition instead of stateful traits / class extension.

For now the common way to add extra instance variable is: you add an extra instance variable named 'properties' in the main class which needs to be committed on the other package, then in the class extension you initialize this varable lazily to a dictionary, and to use extra instance variable, you store/read them in the properties dictionary by overriding the getter/setter method. You can look at the refactoring browser AST which is implemented like that. This way is nice because it is easily optimizable by slots (even if we have not done it yet) and you only add 1 instance variable to the main class whereas you can add an infinite number of instance variables.

Best,

2013/10/31 Tudor Girba <[hidden email]>

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.

Cheers,
Doru

On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <[hidden email]> wrote:

On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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"

kilon.alios

Re: Losing instance variable addition

Wow so much work to add an instance variable ?

In python is as simple as

MyClass.newVariable = 30

I always assumed Pharo was very similar.

On Thu, Oct 31, 2013 at 10:55 AM, Clément Bera <[hidden email]> wrote:

Basically here we discuss how to introduce in Pharo stateful class extension and stateful traits. I like these features a lot because it means I would be able to reuse the same class differently depending on the context and the surrounding classes. But if we overuse that we will definitely go into chaos. Martin tried in Mist and he concluded that he should have class composition instead of stateful traits / class extension.

For now the common way to add extra instance variable is: you add an extra instance variable named 'properties' in the main class which needs to be committed on the other package, then in the class extension you initialize this varable lazily to a dictionary, and to use extra instance variable, you store/read them in the properties dictionary by overriding the getter/setter method. You can look at the refactoring browser AST which is implemented like that. This way is nice because it is easily optimizable by slots (even if we have not done it yet) and you only add 1 instance variable to the main class whereas you can add an infinite number of instance variables.

Best,

2013/10/31 Tudor Girba <[hidden email]>

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.

Cheers,
Doru

On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <[hidden email]> wrote:

On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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"

Marcus Denker-4

Re: Losing instance variable addition

On 31 Oct 2013, at 10:16, kilon alios <[hidden email]> wrote:

> Wow so much work to add an instance variable ?
>
> In python is as simple as
>
> MyClass.newVariable = 30
>
> I always assumed Pharo was very similar.
>
>
Reflectively it is that easy. It’s #addInstVarNamed:

But then the package is dirty. And when you save the package, this Ivar is part of that
package with the class and not part of the package that called #addInstVarNamed:

Marcus

Sven Van Caekenberghe-2

Re: Losing instance variable addition

In reply to this post by kilon.alios

On 31 Oct 2013, at 10:15, kilon alios <[hidden email]> wrote:

> Wow so much work to add an instance variable ?
>
> In python is as simple as
>
> MyClass.newVariable = 30
>
> I always assumed Pharo was very similar.

The discussion is about source code management.
Of course this is very easy in Pharo.

> On Thu, Oct 31, 2013 at 10:55 AM, Clément Bera <[hidden email]> wrote:
> Basically here we discuss how to introduce in Pharo stateful class extension and stateful traits. I like these features a lot because it means I would be able to reuse the same class differently depending on the context and the surrounding classes. But if we overuse that we will definitely go into chaos. Martin tried in Mist and he concluded that he should have class composition instead of stateful traits / class extension.
>
> For now the common way to add extra instance variable is: you add an extra instance variable named 'properties' in the main class which needs to be committed on the other package, then in the class extension you initialize this varable lazily to a dictionary, and to use extra instance variable, you store/read them in the properties dictionary by overriding the getter/setter method. You can look at the refactoring browser AST which is implemented like that. This way is nice because it is easily optimizable by slots (even if we have not done it yet) and you only add 1 instance variable to the main class whereas you can add an infinite number of instance variables.
>
> Best,
>
>
> 2013/10/31 Tudor Girba <[hidden email]>
> 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.
>
> Cheers,
> Doru
>
>
>
>
> On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <[hidden email]> wrote:
>
> On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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"
>
>

kilon.alios

Re: Losing instance variable addition

In reply to this post by Marcus Denker-4

ah ok I understand now. I assume the proper way would be to have 2 dirty packages in this case, one with the changed Class (containing the new instance variable ) and another with the class that sends the message to the mother class to add the instance variable.

On Thu, Oct 31, 2013 at 11:20 AM, Marcus Denker <[hidden email]> wrote:

On 31 Oct 2013, at 10:16, kilon alios <[hidden email]> wrote:

> Wow so much work to add an instance variable ?
>
> In python is as simple as
>
> MyClass.newVariable = 30
>
> I always assumed Pharo was very similar.
>
>

Reflectively it is that easy. It’s #addInstVarNamed:

But then the package is dirty. And when you save the package, this Ivar is part of that
package with the class and not part of the package that called #addInstVarNamed:

Marcus

Camillo Bruni-3

Re: Losing instance variable addition

In reply to this post by Clément Béra

On 2013-10-31, at 09:55, Clément Bera <[hidden email]> wrote:

> Basically here we discuss how to introduce in Pharo stateful class extension and stateful traits. I like these features a lot because it means I would be able to reuse the same class differently depending on the context and the surrounding classes. But if we overuse that we will definitely go into chaos. Martin tried in Mist and he concluded that he should have class composition instead of stateful traits / class extension.

right, using stateful traits a quite a bit different than directly adding inst vars ;).
This way you can easily ensure that the added variable is only visible to the new code and hence you do not run into the override limbo. Now that we have first-class slots, doing these things gets much easier (note that stateful traits was an example implementation in the slot paper).

I think the resulting "mess", which we already have with normal traits, is the lack of tools. For instances, pharo didn't properly respect traits in the IDE for years with the result that most of the trait methods slowly vanished.

signature.asc (457 bytes) Download Attachment

EstebanLM

Re: Losing instance variable addition

I'm with Doru here, we already have the capability of extend completely the system (not just to extend methods). Even if can be dangerous, that's a choice of the user.
Our tools should empower the features of the language, not restrict them.

On Oct 31, 2013, at 7:49 AM, Camillo Bruni <[hidden email]> wrote:

>
> On 2013-10-31, at 09:55, Clément Bera <[hidden email]> wrote:
>
>> Basically here we discuss how to introduce in Pharo stateful class extension and stateful traits. I like these features a lot because it means I would be able to reuse the same class differently depending on the context and the surrounding classes. But if we overuse that we will definitely go into chaos. Martin tried in Mist and he concluded that he should have class composition instead of stateful traits / class extension.
>
> right, using stateful traits a quite a bit different than directly adding inst vars ;).
> This way you can easily ensure that the added variable is only visible to the new code and hence you do not run into the override limbo. Now that we have first-class slots, doing these things gets much easier (note that stateful traits was an example implementation in the slot paper).
>
> I think the resulting "mess", which we already have with normal traits, is the lack of tools. For instances, pharo didn't properly respect traits in the IDE for years with the result that most of the trait methods slowly vanished.

Stéphane Ducasse

Re: Losing instance variable addition

In reply to this post by Igor Stasenko

On Oct 30, 2013, at 10:36 PM, Igor Stasenko <[hidden email]> 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.

Exact this was my conclusion too.
> 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.

If that would be that simple :)
The case of Gisela is that her tool should extend AST node.

Stef

Marcus Denker-4

Re: Losing instance variable addition

On 31 Oct 2013, at 18:12, Stéphane Ducasse <[hidden email]> wrote:

>
> On Oct 30, 2013, at 10:36 PM, Igor Stasenko <[hidden email]> 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.
>
> Exact this was my conclusion too.
>> 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.
>
> If that would be that simple :)
> The case of Gisela is that her tool should extend AST node.

The AST has a property dictionary… not the nicest thing, but it could be used.

Marcus

Stéphane Ducasse

Re: Losing instance variable addition

In reply to this post by Camillo Bruni-3

On Oct 30, 2013, at 10:54 PM, Camillo Bruni <[hidden email]> wrote:

>
> On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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

Sorry but this is not the same as having overrides in Monticello. It is the same as having class extensions!
So class extensions are powerful and we should get the same for instance variables.

Now the real question is not shape is how you garantee that it is well initialized!!!
Because you do not want to extend initialize because it does not work modularly.
Now with slot we can attach initializers to them and then we can get it modular.

Stef

Nicolas Cellier

Re: Losing instance variable addition

And you're going to bump into slot initialization order...

2013/10/31 Stéphane Ducasse <[hidden email]>

On Oct 30, 2013, at 10:54 PM, Camillo Bruni <[hidden email]> wrote:

>
> On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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

Sorry but this is not the same as having overrides in Monticello. It is the same as having class extensions!
So class extensions are powerful and we should get the same for instance variables.

Now the real question is not shape is how you garantee that it is well initialized!!!
Because you do not want to extend initialize because it does not work modularly.
Now with slot we can attach initializers to them and then we can get it modular.

Stef

Nicolas Cellier

Re: Losing instance variable addition

Unless initialization is lazy (and you arrange for avoiding/detecting circular dependency)

2013/10/31 Nicolas Cellier <[hidden email]>

And you're going to bump into slot initialization order...

2013/10/31 Stéphane Ducasse <[hidden email]>

On Oct 30, 2013, at 10:54 PM, Camillo Bruni <[hidden email]> wrote:

>
> On 2013-10-30, at 22:36, Igor Stasenko <[hidden email]> 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

Sorry but this is not the same as having overrides in Monticello. It is the same as having class extensions!
So class extensions are powerful and we should get the same for instance variables.

Now the real question is not shape is how you garantee that it is well initialized!!!
Because you do not want to extend initialize because it does not work modularly.
Now with slot we can attach initializers to them and then we can get it modular.

Stef