Hi klaus
> Hi Stef, > > I want to get rid of "Behavior class #new" because it can not be > overridden on the instance side by #initialize. Do you mean that instead of Behavior class>>new | classInstance | classInstance := self basicNew. classInstance methodDictionary: classInstance emptyMethodDictionary. classInstance superclass: Object. classInstance setFormat: Object format. ^ classInstance You would like to have Behavior>>new ^ self basicNew initialize. Behavior>>initialize self methodDictionary: self emptyMethodDictionary. self superclass: Object. self setFormat: Object format. ^ self And not Behavior class>>new I tried and it seems to work. Indeed I guess that it could make sense. I'm thinking about the result of doing that. Right now when we send a message new to a class this is not the new of Behavior but of Behavior class. I sent the email to the list because I sugar low now and moving boxes around so I would appreciate feedback on this one. Stef > In my subclass of ClassDescription I currently am forced to > override #new on the class side :-( > > Does anything speak against NOT having any #new, #new:, etc, never > +ever on the *class* side of Behavior(s)? > > Best regards, > Klaus > > P.S. Thank you Daniel for your insightful response. > > ------- Forwarded message ------- > From: "Daniel Vainsencher" <[hidden email]> > To: "Klaus D. Witzel" <[hidden email]> > Cc: > Subject: Re: Squeak 3.8/3.9 and Behavior class new > Date: Sun, 14 May 2006 10:11:59 +0200 > > Hi Klaus! > > I'm sorry, but I can't help you. > > If you look at the versions, you'll see that Stef Ducasse saved the > exact same code before me, so maybe he'll know. My guess is that my > name > is only there because of code-moving operations needed during > traits. If > you're not doing so, I would recommend you use the traits browser when > working with the kernel code, otherwise you have no way of knowing > whether the Behavior>>new is actually composed in from a Traits (quite > likely, though I didn't check). > > If you don't know how to install the Traits browser, ask on the list, > I'm sure there are others that don't, and someone that does. > > Daniel > > Klaus D. Witzel wrote: >> Hi Daniel, >> >> found your initials in the Behavior class #new method. >> Unfortunately this behavior (Behavior class's behavior, I mean) >> cannot be overridded except by overriding #new (which many people, >> including me, are reluctant to do). I created a subclass of >> ClassDescription and was wondering *where* instances of my class >> where initialized and it took me a while to realize it was hacked >> into #new on the class side of Behavior. >> >> Does anything speak against moving your initializing code to the >> instance side of Behavior, into an #initialize method (following >> the general pattern of how #new is implemented)? I ask because I >> do not want to break the implementation of traits (which I assume >> was the reason for introducing the above beginning with 3.8). >> >> Kind regards, >> Klaus D. Witzel >> [hidden email] >> > > > |
> You would like to have
> > Behavior>>new > > ^ self basicNew initialize. > > Behavior>>initialize > > self methodDictionary: self emptyMethodDictionary. > self superclass: Object. > self setFormat: Object format. > ^ self I just tried and it works. I also tried to break it when creating subclasses, but I was not successful. Let's assume a class A, for which: A class>>initialize " do nothing" I was wondering why I can still create a subclass of A. Actually, when a subclass is created, Behavior>>new is called on the class Metaclass. Then, this instance of Metaclass is initialized with a superclass and an empty dictionary (ClassBuilder>>privateNewSubclassOf:) Interesting... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.cs.tcd.ie/Alexandre.Bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Hi Alex,
on Sun, 14 May 2006 13:04:16 +0200, Ayou <[hidden email]> wrote: >> You would like to have >> >> Behavior>>new >> >> ^ self basicNew initialize. >> >> Behavior>>initialize >> >> self methodDictionary: self emptyMethodDictionary. >> self superclass: Object. >> self setFormat: Object format. >> ^ self > > I just tried and it works. I also tried to break it when creating > subclasses, but I was not successful. > Let's assume a class A, for which: > A class>>initialize > " do nothing" > > I was wondering why I can still create a subclass of A. The hack looks like it was necessary when migrating the image to Traits. But now Traits have arrived at 3.9b and Behavior>>initialize can again behave <grin> like a regular citizen. > Actually, when a subclass is created, Behavior>>new is called on the > class Metaclass. Then, this instance of Metaclass is initialized with a > superclass and an empty dictionary (ClassBuilder>>privateNewSubclassOf:) Sure. ClassBuilder wants to be independent+under+all+circumstances, that's why there are so many setters+getters for Behavior withAllSubclasses. I guess some of them (getters+setters) can be consolidated with Traits, thereby encapsulating behavior instead of just accessing behavioral state. > Interesting... :-) /Klaus > Alexandre |
No this has nothing to do with traits.
I did that when I fixed the fact that we could do Behavior new. Still I would like to take the time to think about the implications of the changes. :) Stef |
Hi Stef,
on Sun, 14 May 2006 14:53:10 +0200, you <[hidden email]> wrote: > No this has nothing to do with traits. > I did that when I fixed the fact that we could do Behavior new. So the change is sort of invariant (and apparently until now had no impact Behavior's subclasses, that is). > Still I would like to take the time to think about the implications of > the changes. :) Np, go ahead and put the "think" silver plate onto your desktop ;-) /Klaus > Stef > > |
Free forum by Nabble | Edit this page |