October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] My talk today at Smalltalks 2013

by Esteban Lorenzano

ouch! On Oct 31, 2013, at 8:03 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Cool. Just a notice, Spec is mentioned two times on slide 4. > > -- Pavel > > 2013/10/30 Esteban Lorenzano <estebanlm(a)gmail.com>: >> Here are the slides: >> >> http://www.slideshare.net/pharoproject/smalltalks13-pharo-techoverview >> >> I think it didn't went so bad... :) >> >> Esteban >> >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Esteban Lorenzano

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 <camillobruni(a)gmail.com> wrote: > > On 2013-10-31, at 09:55, ClÃ©ment Bera <bera.clement(a)gmail.com> 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.

Oct. 31, 2013

Changes in change browser or lists, a bug?

by Gisela Decuzzi

I wanted to navigate between changes in change browser and it seems that is only possible using the checkbox, here is the case: https://pharo.fogbugz.com/f/cases/12046/Select-change-in-changeBrowser-clic… But not sure if this is a bug

Oct. 31, 2013

Re: [Pharo-dev] My talk today at Smalltalks 2013

by Pavel Krivanek

Cool. Just a notice, Spec is mentioned two times on slide 4. -- Pavel 2013/10/30 Esteban Lorenzano <estebanlm(a)gmail.com>: > Here are the slides: > > http://www.slideshare.net/pharoproject/smalltalks13-pharo-techoverview > > I think it didn't went so bad... :) > > Esteban >

Oct. 31, 2013

Jenkins Down

by Camillo Bruni

With a one day grace period [1] all our Jenkins instances are now down, the only slaves that remains is our mac slave. [1] https://wiki.inria.fr/ciportal/Event_20131030_cs best regards, camillo

Oct. 31, 2013

Re: [Pharo-dev] My talk today at Smalltalks 2013

by Esteban A. Maringolo

Nice talk Esteban! I wish I was there.

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Camillo Bruni

On 2013-10-31, at 09:55, ClÃ©ment Bera <bera.clement(a)gmail.com> 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.

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by kilon alios

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 <marcus.denker(a)inria.fr>wrote: > > On 31 Oct 2013, at 10:16, kilon alios <kilon.alios(a)gmail.com> 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 > > > >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Sven Van Caekenberghe

On 31 Oct 2013, at 10:15, kilon alios <kilon.alios(a)gmail.com> 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 <bera.clement(a)gmail.com> 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 <tudor(a)tudorgirba.com> > 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 <camillobruni(a)gmail.com> wrote: > > On 2013-10-30, at 22:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > I don't think there's something to fix. > > You cannot 'extend' classes belonging to other package in any other way > > than adding extension methods. > > Allowing extension of ivars or any other vars by foreign package > > is road to nowhere. > > > > I would not like if shape of my kernel classes depends on what packages i load > > or in what order i loaded them. > > To me it is clear that if one needs to add/remove/modify instance variables > > of some class, those changes should belong to the package containing that class, > > not some random package. > > Exactly, it would cause the same problem as we have with overrides in monticello > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Marcus Denker

On 31 Oct 2013, at 10:16, kilon alios <kilon.alios(a)gmail.com> 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

Oct. 31, 2013