June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Sean P. DeNigris

Igor Stasenko wrote > > because 'announcer weak subscribe: ' is explicit > Either way, something is implicit. Why not make the common case implicit and the uncommon one slightly more verbose? "Make common things easy, rare things possible" b.t.w. I like that we are all independently discovering many of the same things. It makes me think we're really on the right track... http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4083086.html -- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnounce… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 16, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

On 16 June 2012 23:12, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > So, what about making weak a default and notWeak the explicit one? :D > you can, but this could lead to confusion. because 'announcer weak subscribe: ' is explicit while 'announcer subscribe: ' is implicit.. so i would leave it like it is now. > > On Sat, Jun 16, 2012 at 11:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > Hi, with the help of Guille I noticed that normal instances usually >> > register >> > weakly: >> > >> > TestRunner >> initialize >> > ..... >> > SystemAnnouncer current >> > Â Â Â Â Â Â weak >> > Â Â Â Â Â Â on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, >> > ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: >> > self. >> > ..... >> > >> > and classes don't: >> > >> > TestCase class >> registerForNotifications >> > Â Â Â ... >> > Â Â SystemAnnouncer current on: MethodAdded, MethodModified, >> > MethodRemoved >> > send: #methodChanged: to: self. >> > >> > so..Guille told me this is because usually the cycle-life of instances >> > is >> > short in comparisson with classes. But classes can be removed as well. >> > What >> > happen then? the announcer will hold always a reference to an obsolete >> > class? >> > my question is, should we always use weakly? if not, why ? >> > >> >> Yes, i think most of subscriptions should be weak, because it is kind >> of implied by loose-coupling. >> And classes is not an exception - because then you don't need to >> explicitly unsubscribe, >> and don't have to worry that it kept in memory just because you forgot to >> do it. >> >> > thanks for the explanation, >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

June 16, 2012

[Pharo-project] what is the status of the monkey?

by Mariano Martinez Peck

ulyses. Where is it? why is it not working? how can I make the monkey pick a particular issue? thanks -- Mariano http://marianopeck.wordpress.com

June 16, 2012

Re: [Pharo-project] #anyChanges still needed?

by Benjamin

My 2cts is for some event (and I think *modified is part of them), you got the event twice: before and after. So basically, one of the two events is wrong. Mariano, you should try to put an halt, and see :) Ben On Jun 16, 2012, at 10:26 PM, Guillermo Polito wrote: > Yeah, but logging superfluous changes does not really make a change, does it? > > On Sat, Jun 16, 2012 at 10:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > may be because the source changes was listening to the event. > And the log file needed to log any thing like doits and other. > > On Jun 16, 2012, at 9:14 PM, Mariano Martinez Peck wrote: > > > Hi guys. ChangeSet does at some point: > > > > anEvent itemKind = SystemChangeNotifier classKind ifTrue: [ > > ... > > anEvent isModified > > ifTrue: [anEvent anyChanges ifTrue: [self changeClass: anEvent item from: anEvent oldItem]]. > > anEven > > > > > > > > So...I don't understand the #anyChanges. We received an event saying that a class was modified, but it may not have any changes? if true, why was the event sent? > > Ok...let's say that there could be several reasons that a class was modified but only some of them make sense to change set. I can imagine people wanted to avoid writing stuff to .changes that didn't actullay represente a change? > > > > If this is the case, then #anyChanges looks like a bad name for me. > > > > Now, do we still need this mesage? can there be ClassModified events without changes? > > thanks > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

June 16, 2012

[Pharo-project] senders search symbols, class references shouldn't do it as well?

by Mariano Martinez Peck

If I search senders of 'foo' I do get those method that has #foo inside. However, if I search class references to Bar, it doesn't found methods that have something like Smalltalk at: #Bar. shouldn't it also find this? thanks -- Mariano http://marianopeck.wordpress.com

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by Nicolas Cellier

2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Jun 16, 2012, at 11:00 AM, Nicolas Cellier wrote: > >> 2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> >>>> On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> why do you need an automatic new method? >>>>> Because by default >>>>> Â new invoke initialize >>>>> >>>>> and it works well. >>>>> >>>> >>>> StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. >>> >>> yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk >> >> Another point of view: creating an instance is on class side > > what is the class side? :) > I would explain it this way, as viewed from a st-80 browser: - you select instance radio button, and see the messages you can send to instances of the class. - you select class radio button, and see the messages you can send to the class itself. Of course, it's not exactly that simple because of inheritance: the browser doesn't show the messages implemented in superclasses that we can send too. There are hierarchy browsers... Except they don't really help with class side inheritance, that's what make it complex for noobs IMO. >> because >> instances are created from a kind of structural template (how many >> variables, etc...). You can also create an instance by cloning with >> copyâ¦ > > I have been there. Teaching a lot during many years and there is no simple explanation: after two hours of lecture you do not want to explain metaclasses. Just because people forgot (CLOS did not do this mistake) to invoke an initialize method when creating an object. > > At the end I added in all my system the Behavior new>> self basicNew initialize > and the students were happy and me too. > Sure, I also find this addition valuable beside teaching. Nicolas > >> But initialize is on instance size because it modifies the private >> instance variables: >> one object can't directly modify another, except by kindly asking by >> sending a message. >> The instance is an object, the class is another, so the class kindly >> ask the instance to initialize itself. >> >> There's no trick here and it can't be more clear. >> The only trick is how a class side new inherits from instance side >> Behavior new, but we don't need this to explain initialize... >> >> Nicolas >> > >

June 16, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Guillermo Polito

So, what about making weak a default and notWeak the explicit one? :D On Sat, Jun 16, 2012 at 11:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi, with the help of Guille I noticed that normal instances usually > register > > weakly: > > > > TestRunner >> initialize > > ..... > > SystemAnnouncer current > > weak > > on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, > > ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. > > ..... > > > > and classes don't: > > > > TestCase class >> registerForNotifications > > ... > > SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved > > send: #methodChanged: to: self. > > > > so..Guille told me this is because usually the cycle-life of instances is > > short in comparisson with classes. But classes can be removed as well. > What > > happen then? the announcer will hold always a reference to an obsolete > > class? > > my question is, should we always use weakly? if not, why ? > > > > Yes, i think most of subscriptions should be weak, because it is kind > of implied by loose-coupling. > And classes is not an exception - because then you don't need to > explicitly unsubscribe, > and don't have to worry that it kept in memory just because you forgot to > do it. > > > thanks for the explanation, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Best regards, > Igor Stasenko. > >

June 16, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi, with the help of Guille I noticed that normal instances usually register > weakly: > > TestRunner >> initialize > ..... > SystemAnnouncer current > Â Â Â Â Â Â weak > Â Â Â Â Â Â on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, > ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. > ..... > > and classes don't: > > TestCase class >> registerForNotifications > Â Â Â ... > Â Â SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved > send: #methodChanged: to: self. > > so..Guille told me this is because usually the cycle-life of instances is > short in comparisson with classes. But classes can be removed as well. What > happen then? the announcer will hold always a reference to an obsolete > class? > my question is, should we always use weakly? if not, why ? > Yes, i think most of subscriptions should be weak, because it is kind of implied by loose-coupling. And classes is not an exception - because then you don't need to explicitly unsubscribe, and don't have to worry that it kept in memory just because you forgot to do it. > thanks for the explanation, > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by Igor Stasenko

In fact, a new instance IS initialized by VM, by putting nil values to each slot and zeroes in case of byte array. What happens next, when you sending #initialize? Yes, you rewriting these values by own, which sound like initial nil-out of all slots was unnecessary. So, in some cases it could be less wasteful (in terms of performance) to just make a copy of existing instance: SomeClass>>initialize preinitializedInstance := self basicNew initialize. SomeClass>>new ^ preinitializedInstance shallowCopy. and this actually a bit faster , except from, of course if #initialize also creating new objects, then cannot avoid extra initialization step. Also, often you cannot fully initialize object using just #initialize because it requires some additional arguments to initialize properly. For that many languages having so-called constructors, where you cannot obtain an instance with not properly initialized state because you have to use constructors when creating new instance. -- Best regards, Igor Stasenko.

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Guillermo Polito

I do not know... Python and Ruby are kind of popular too without needing such kind of prefixes... I thing we should be original in the name :), and that's all... On Sat, Jun 16, 2012 at 10:50 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > http://en.wikipedia.org/wiki/Java_version_history isn't too bad either > with Update x suffix. > > Pharo SE 4 Update 2 ... there is some good marketing touch to that > given the popularity of Java. > > They switched after 1.4 - As an innovative platform, maybe we can switch > now :-) > > 2.0 would become Pharo SE 5 > and things like Seaside would be Pharo WE 6 (Web Edition) > and moose Pharo DE 4 (Data visualization Edition) > > Phil > > 2012/6/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos(a)gmx.net> > wrote: > >> > >> On 13.06.2012 11:08, Esteban Lorenzano wrote: > >>> > >>> Hi, > >>> > >>> I started thinking on next release of Pharo 1.4 (which will be code > named > >>> "summer", not an ugly number). > >> > >> > >> It's only summer in the northern hemisphere. Eclipse renamed their > winter > >> releases because it isn't winter in February in half of the world. > >> > > > > +1 to simply call it 1.4.1 > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > >

June 16, 2012