Re: [Pharo-dev] Losing instance variable addition
> > This is not the same :) > > What is not the same? :) By "override" I meant the problem induced by two > packages that define the same method, and that are being loaded at the same > time. ah that yes but it will probably never happen in reality :) I thought more about method extensions Stef
Re: [Pharo-dev] Losing instance variable addition
Hi Stef, On Thu, Oct 31, 2013 at 6:49 PM, Stéphane Ducasse wrote: > > On Oct 31, 2013, at 8:25 AM, Tudor Girba 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. > > 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 :) > What is not the same? :) By "override" I meant the problem induced by two packages that define the same method, and that are being loaded at the same time. Cheers, Doru > > 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 wrote: > >> >> On 2013-10-30, at 22:36, Igor Stasenko 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" > > > -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Losing instance variable addition
I agree. I do not see why we make the situation so complicated. Extending a class with state is the same conceptually as is extending it with methods. The same type of problems apply. We can extend a class with methods, and we know it is powerful. Yes, you can have problems with overrides sometimes, but in practice, method extensions collision occurs rarely now. With a little discipline, you can get things to work quite nicely. And again, it is the responsibility of the extender to manage the extensions. Doru On Fri, Nov 1, 2013 at 4:36 AM, Stéphane Ducasse wrote: > > On Oct 31, 2013, at 11:37 PM, Igor Stasenko wrote: > > > > > Btw, if you remember, i already proposed how to solve 'extending > object's state with arbitrary state' , mainly by changing the object format > to support variable number of key-value properties per object. > > Similar to javascript or self, where you can define a new property on a > per-object basis. > > This is fairly easy to implement, at VM level, just reserve extra field > in object format, > > define the format of key/value dictionary and add primitives to retrieve > and store key-based properties for objects. > > What i like in it, that at language side it is cost nothing: you don't > have to extend > > the language to formally define the slots (but you may, of course), > > and there's nothing preventing you from using private keys and not > giving them away > > to anyone to keep your data private and not exposing it globally (except > from reflection tools i guess). > > And, what is important, you are free to use them or not.. and it costs > almost nothing in terms of performance, and nothing in terms of formalism > and extra rules in language/package/source management etc etc > > you do not need to be at the object level. For me this would be another > level of mess. > > When you think about class extensions we get them because methods are not > in the scope of the their class > so it was easy to define a method into a file that represented another > changeset. > Now we have problem with iv extensions because they are scoped by the > class definition. > > Stef > > > > -- > > Best regards, > > Igor Stasenko. > > > > > -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Losing instance variable addition
On 1 November 2013 03:36, Stéphane Ducasse wrote: > > On Oct 31, 2013, at 11:37 PM, Igor Stasenko wrote: > >> >> Btw, if you remember, i already proposed how to solve 'extending object's >> state with arbitrary state' , mainly by changing the object format to >> support variable number of key-value properties per object. >> Similar to javascript or self, where you can define a new property on a >> per-object basis. >> This is fairly easy to implement, at VM level, just reserve extra field in >> object format, >> define the format of key/value dictionary and add primitives to retrieve and >> store key-based properties for objects. >> What i like in it, that at language side it is cost nothing: you don't have >> to extend >> the language to formally define the slots (but you may, of course), >> and there's nothing preventing you from using private keys and not giving >> them away >> to anyone to keep your data private and not exposing it globally (except >> from reflection tools i guess). >> And, what is important, you are free to use them or not.. and it costs >> almost nothing in terms of performance, and nothing in terms of formalism >> and extra rules in language/package/source management etc etc > > you do not need to be at the object level. For me this would be another level > of mess. > > When you think about class extensions we get them because methods are not in > the scope of the their class > so it was easy to define a method into a file that represented another > changeset. > Now we have problem with iv extensions because they are scoped by the class > definition. Does this imply that the correct scope for a class extension would be per package? Say package Base defines a class Foo and package Ext adds a slot to Foo, could you model this through an (Squeak) Environment-like way like this?: In your application's Environment Env, Foo is as it's defined by the Base package. When you load Foo into Env, Env stores a _subclass_ of Foo Foo1, adding the slot to Foo1. But Env actually maps Foo1 to Foo. Within Env, looking up "Foo" means finding Foo1, with the extension. In any other Environment, looking up "Foo" finds Foo, without the extension. (This is how I think extending classes with methods should work too, but I'll be the first to admit that this idea is a "what if we..." idea without any real thought into how feasible it is.) frank > Stef >> >> -- >> Best regards, >> Igor Stasenko. >> > >
Re: [Pharo-dev] Losing instance variable addition
On Oct 31, 2013, at 11:37 PM, Igor Stasenko wrote: > > Btw, if you remember, i already proposed how to solve 'extending object's > state with arbitrary state' , mainly by changing the object format to support > variable number of key-value properties per object. > Similar to javascript or self, where you can define a new property on a > per-object basis. > This is fairly easy to implement, at VM level, just reserve extra field in > object format, > define the format of key/value dictionary and add primitives to retrieve and > store key-based properties for objects. > What i like in it, that at language side it is cost nothing: you don't have > to extend > the language to formally define the slots (but you may, of course), > and there's nothing preventing you from using private keys and not giving > them away > to anyone to keep your data private and not exposing it globally (except from > reflection tools i guess). > And, what is important, you are free to use them or not.. and it costs almost > nothing in terms of performance, and nothing in terms of formalism and extra > rules in language/package/source management etc etc you do not need to be at the object level. For me this would be another level of mess. When you think about class extensions we get them because methods are not in the scope of the their class so it was easy to define a method into a file that represented another changeset. Now we have problem with iv extensions because they are scoped by the class definition. Stef > > -- > Best regards, > Igor Stasenko. >
Re: [Pharo-dev] Losing instance variable addition
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 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
> wrote:
>
> On 2013-10-30, at 22:36, Igor Stasenko 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.
Re: [Pharo-dev] Losing instance variable addition
Btw, if you remember, i already proposed how to solve 'extending object's state with arbitrary state' , mainly by changing the object format to support variable number of key-value properties per object. Similar to javascript or self, where you can define a new property on a per-object basis. This is fairly easy to implement, at VM level, just reserve extra field in object format, define the format of key/value dictionary and add primitives to retrieve and store key-based properties for objects. What i like in it, that at language side it is cost nothing: you don't have to extend the language to formally define the slots (but you may, of course), and there's nothing preventing you from using private keys and not giving them away to anyone to keep your data private and not exposing it globally (except from reflection tools i guess). And, what is important, you are free to use them or not.. and it costs almost nothing in terms of performance, and nothing in terms of formalism and extra rules in language/package/source management etc etc -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Losing instance variable addition
On 31 October 2013 22:52, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> 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
>
>>
>>
>>
>> On 31 October 2013 22:37, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> 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
>>>
On 31 October 2013 08:25, Tudor Girba 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 wrote:
>>
>> > I don't thi
Re: [Pharo-dev] Losing instance variable addition
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
>
>
>
> On 31 October 2013 22:37, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> 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
>>
>>>
>>>
>>>
>>> On 31 October 2013 08:25, Tudor Girba 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 >>> > wrote:
>
> On 2013-10-30, at 22:36, Igor Stasenko 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.
>>>
Re: [Pharo-dev] Losing instance variable addition
On 31 October 2013 22:37, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> 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
>
>>
>>
>>
>> On 31 October 2013 08:25, Tudor Girba 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
>>> wrote:
>>>
On 2013-10-30, at 22:36, Igor Stasenko 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.
Re: [Pharo-dev] Losing instance variable addition
On 31 October 2013 18:49, Stéphane Ducasse wrote:
>
> On Oct 31, 2013, at 8:25 AM, Tudor Girba 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
anti-modular
by definition.
I would much more prefer instead of saying:
Package A is: {
extends: Object withSlot: x
}
saying:
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 wrote:
>
>>
>> On 2013-10-30, at 22:36, Igor Stasenko 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.
Re: [Pharo-dev] Losing instance variable addition
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 ;)
2013/10/31 Igor Stasenko
>
>
>
> On 31 October 2013 08:25, Tudor Girba 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
>> wrote:
>>
>>>
>>> On 2013-10-30, at 22:36, Igor Stasenko 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.
>
Re: [Pharo-dev] Losing instance variable addition
On 31 October 2013 08:25, Tudor Girba 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 wrote:
>
>>
>> On 2013-10-30, at 22:36, Igor Stasenko 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.
Re: [Pharo-dev] Losing instance variable addition
On Oct 31, 2013, at 8:25 AM, Tudor Girba 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. > 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 > wrote: > > On 2013-10-30, at 22:36, Igor Stasenko 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"
Re: [Pharo-dev] Losing instance variable addition
On Oct 31, 2013, at 6:37 PM, Nicolas Cellier wrote: > Or, you infer the right order, for example from the AST of each initializer > you should be able to get the dependency graph... > My own preference goes to laziness ;) me too. Same for ClassVariables they should be totally self initializable without dependencies. Stef > > > 2013/10/31 Nicolas Cellier > Unless initialization is lazy (and you arrange for avoiding/detecting > circular dependency) > > > 2013/10/31 Nicolas Cellier > And you're going to bump into slot initialization order... > > > 2013/10/31 Stéphane Ducasse > > On Oct 30, 2013, at 10:54 PM, Camillo Bruni wrote: > > > > > On 2013-10-30, at 22:36, Igor Stasenko 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 > > > > >
Re: [Pharo-dev] Losing instance variable addition
Or, you infer the right order, for example from the AST of each initializer you should be able to get the dependency graph... My own preference goes to laziness ;) 2013/10/31 Nicolas Cellier > Unless initialization is lazy (and you arrange for avoiding/detecting > circular dependency) > > > 2013/10/31 Nicolas Cellier > >> And you're going to bump into slot initialization order... >> >> >> 2013/10/31 Stéphane Ducasse >> >>> >>> On Oct 30, 2013, at 10:54 PM, Camillo Bruni >>> wrote: >>> >>> > >>> > On 2013-10-30, at 22:36, Igor Stasenko 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 >>> >>> >>> >> >
Re: [Pharo-dev] Losing instance variable addition
Unless initialization is lazy (and you arrange for avoiding/detecting circular dependency) 2013/10/31 Nicolas Cellier > And you're going to bump into slot initialization order... > > > 2013/10/31 Stéphane Ducasse > >> >> On Oct 30, 2013, at 10:54 PM, Camillo Bruni >> wrote: >> >> > >> > On 2013-10-30, at 22:36, Igor Stasenko 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 >> >> >> >
Re: [Pharo-dev] Losing instance variable addition
And you're going to bump into slot initialization order... 2013/10/31 Stéphane Ducasse > > On Oct 30, 2013, at 10:54 PM, Camillo Bruni > wrote: > > > > > On 2013-10-30, at 22:36, Igor Stasenko 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 > > >
Re: [Pharo-dev] Losing instance variable addition
On Oct 30, 2013, at 10:54 PM, Camillo Bruni wrote: > > On 2013-10-30, at 22:36, Igor Stasenko 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
Re: [Pharo-dev] Losing instance variable addition
On 31 Oct 2013, at 18:12, Stéphane Ducasse wrote: > > On Oct 30, 2013, at 10:36 PM, Igor Stasenko 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
Re: [Pharo-dev] Losing instance variable addition
On Oct 30, 2013, at 10:36 PM, Igor Stasenko 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
Re: [Pharo-dev] 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 wrote: > > On 2013-10-31, at 09:55, Clément Bera 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.
Re: [Pharo-dev] Losing instance variable addition
On 2013-10-31, at 09:55, Clément Bera 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 Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Losing instance variable addition
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 wrote: > > On 31 Oct 2013, at 10:16, kilon alios 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 > > > >
Re: [Pharo-dev] Losing instance variable addition
On 31 Oct 2013, at 10:15, kilon alios 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 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 > 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 > wrote: > > On 2013-10-30, at 22:36, Igor Stasenko 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" > >
Re: [Pharo-dev] Losing instance variable addition
On 31 Oct 2013, at 10:16, kilon alios 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
Re: [Pharo-dev] 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 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 > >> 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 >> wrote: >> >>> >>> On 2013-10-30, at 22:36, Igor Stasenko 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" >> > >
Re: [Pharo-dev] 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 > 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 wrote: > >> >> On 2013-10-30, at 22:36, Igor Stasenko 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" >
Re: [Pharo-dev] 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 wrote: > > On 2013-10-30, at 22:36, Igor Stasenko 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"
Re: [Pharo-dev] Losing instance variable addition
On 2013-10-30, at 22:36, Igor Stasenko 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 Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Losing instance variable addition
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 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.
Re: [Pharo-dev] 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 > 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 > 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 > >> > >> > > > > >
Re: [Pharo-dev] 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 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 >> >> >
Re: [Pharo-dev] 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 > >
Re: [Pharo-dev] 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
[Pharo-dev] 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
