- Pharo-dev - lists.pharo.org

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

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

by Mariano Martinez Peck

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 ? thanks for the explanation, -- Mariano http://marianopeck.wordpress.com

June 16, 2012

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

by phil＠highoctane.be

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

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

by phil＠highoctane.be

Anyway, we need to learn if we want to create things with something else than new... But I like basicNew initialize the way it is now. 2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> StÃ©phane, would you mind expanding a bit on what mistake CLOS didn't make? > > create-instance invokes initialize-instance in CLOS for every class. > > In Smalltalk (not squeak or pharo), new does not invoke initialize. Now CLOS arrived 10 years after Smalltalk and we fixed > that problem in our lovely environment. > > Stef > > -- 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

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

by phil＠highoctane.be

We are closing the gap with Java versions... Pharo 1.6.3_047 nearing... 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

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

by Guillermo Polito

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