Being new not only to Smalltalk, but OOP in general, I think I finally am understanding things. One area I am still unsure about is the class side versus the instance side. Does one usually use the class side when they want those inherited in every subclass, which frees one from having to declare them in every instance? TIA for reading my silly questions. |
Administrator
|
On Tue, Jul 28, 2020 at 4:35 PM G B via Pharo-users <[hidden email]> wrote:
One of the important concepts in Smalltalk is that *everything* is an object. When we say "class side" and "instance side", we are using a shorthand for the two objects involved. In most Smalltalks, the "class side" is really a meta-class and the "instance side" is really the class. The browser is designed to present them together because it makes sense to do that. Both sets of behaviours and variables are inherited by subclasses. [I'm playing a little loose here, as there is a distinction between a Class Variable and a Class Instance Variable in the meta-class.] The meta-class/"class side" typically deals with instance creation and management. The "instance side" provides the behaviours associated with the instances of the class.
Not silly at all. This is a somewhat opaque topic since the browser makes it appear less obvious. |
In reply to this post by Pharo Smalltalk Users mailing list
Hi,
The "class vs instance" side is one of the most confusing things for newcomers, I remember struggling with it when I learnt Smalltalk (and also was a novice in OOP). It helps you thinking it this way: the instance side is everything that will affect all instances of such class, and you can think the "class side" as what affect the factory for these instances (the sole instance of the class). E.g. let's say you have a "Dog". Dog instances will have a #bark method, and maybe a "color" property (via an instance variable). So when you do: dog1 := Dog new. dog1 color: Color white. dog2 := Dog new. dog2 color: Color black. You have two instances of Dog, and each one with its own color. Both understand the #bark message. But the Dog (capitalized) there, references the Dog class itself (aka "the class side" of Dog) and #new is a method of the "class side" of Dog. So if you implement a #newWhite method in the "class side" of Dog, it would be something like this. Dog class>>newWhite "Returns a new white instance of receiver." ^self new color: Color white In this method the "self new" refers to the class itself, not to the "instance" of the dog, but the returned object of "new" is an instance, and there the #color: message is sent to the instance of Dog. I hope this explanation helps, the meta relations involved in this are more complex than what I explained, but I hope this helps you get started. Regards! Esteban A. Maringolo On Tue, Jul 28, 2020 at 8:35 PM G B via Pharo-users <[hidden email]> wrote: > > Being new not only to Smalltalk, but OOP in general, I think I finally am understanding things. One area I am still unsure about is the class side versus the instance side. Does one usually use the class side when they want those inherited in every subclass, which frees one from having to declare them in every instance? > > TIA for reading my silly questions. |
In reply to this post by Pharo Smalltalk Users mailing list
Hello patrick
Welcome
It does not contain the answer but …
Class side instances are - to share state among all instances (including subinstances) - state for classes. You have classVariables (should be renamed sharedVariables) and this is different from class instance variables (which are just instance variables of classes and since classes are kind of global you can use also to have act as shared variables). The difference being that there is only one classVar(sharedVariable) per hierarchy while you have one class instance variable per class. S.
|
In reply to this post by Esteban A. Maringolo
Shouldn't this code
> So if you implement a #newWhite method in the "class side" of Dog, it > would be something like this. > > Dog class>>newWhite > "Returns a new white instance of receiver." > ^self new color: Color white be this instead? > Dog class>>newWhite > "Returns a new white instance of receiver." > ^self new > color: Color white; > yourself in order to return the new Dog instance? Otherwise it will return the Dog class itself (not what you expected? -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
On August 2, 2020 9:25:32 AM PDT, tbrunz <[hidden email]> wrote: >Shouldn't this code > >> So if you implement a #newWhite method in the "class side" of Dog, it >> would be something like this. >> >> Dog class>>newWhite >> "Returns a new white instance of receiver." >> ^self new color: Color white > >be this instead? > >> Dog class>>newWhite >> "Returns a new white instance of receiver." >> ^self new >> color: Color white; >> yourself > >in order to return the new Dog instance? Otherwise it will return the >Dog >class itself (not what you expected? No. It cannot answer the class. It will answer the result of the last message send. That could be the new instance OR the result of sending #white to Color. This latter point is the reason why people generally like to include the #yourself message in the cascade. > >-t > > > >-- >Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Thanks, Richard.
So adding #yourself is mostly needed for cases where you send #add: to an OrderedCollection (because that returns the added element instead of returning the collection as most expect it would)? I've been adding it in all cases, which I guess does no harm. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
On August 2, 2020 10:16:54 AM PDT, tbrunz <[hidden email]> wrote: >Thanks, Richard. > >So adding #yourself is mostly needed for cases where you send #add: to >an >OrderedCollection (because that returns the added element instead of >returning the collection as most expect it would)? No. It is used when you don't know what the last message send answers. And, *that* is most of the time, because even when you know the answer today, you don't know the future changes. > >I've been adding it in all cases, which I guess does no harm. That is the correct answer. Add it unless you want the result of the last message send. > >-t > > > >-- >Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Got it. Seems like an important point for those who are trying to understand
the difference between instances and classes. I've gotten strange results myself until I learned that #yourself is an essential thing... -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
In reply to this post by Richard Sargent (again)
+1
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
In reply to this post by tbrunz
ted basically
Dog class>>newWhite is equivalent to Dog class>>newWhite | instance |instance := self new. instance color: Color white; ^ instance So this is really when you do not know what a subclass may do with reimplementing color: so yourself make sure that your extenders can be doing crazy things, your job is good. S.
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
Maybe more to the point: You do not want to *code a dependency on* what the
implementing class may do as far as the returned result. :^) "Brittle code" will eventually break. Murphy's Law says that it will break at the worst possible time for you to have to deal with it. :^D -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Free forum by Nabble | Edit this page |