Class side vs instance side (variables and methods)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Class side vs instance side (variables and methods)

Pharo Smalltalk Users mailing list
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.
Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Richard Sargent
Administrator
On Tue, Jul 28, 2020 at 4: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?

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.


TIA for reading my silly questions.

Not silly at all. This is a somewhat opaque topic since the browser makes it appear less obvious.

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Esteban A. Maringolo
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.

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Stéphane Ducasse
In reply to this post by Pharo Smalltalk Users mailing list
Hello patrick

Welcome


Subject: Class side vs instance side (variables and methods)
Date: 29 July 2020 at 01:34:22 CEST
To: Any Question About Pharo Is Welcome <[hidden email]>


Being new not only to Smalltalk, but OOP in general, I think I finally am understanding things.

Did you read my learning OOP book?
It does not contain the answer but …

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?

No

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. 
Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

tbrunz
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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Richard Sargent (again)


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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

tbrunz
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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Richard Sargent (again)


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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

tbrunz
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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Stéphane Ducasse
In reply to this post by Richard Sargent (again)
+1 


On 2 Aug 2020, at 19:37, Richard Sargent <[hidden email]> wrote:



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


--------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

Stéphane Ducasse
In reply to this post by tbrunz
ted basically 

Dog class>>newWhite
 "Returns a new white instance of receiver."
 ^self new 
   color: Color white;
   yourself


is equivalent to 

Dog class>>newWhite
 "Returns a new white instance of receiver.”

  | 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. 


On 2 Aug 2020, at 19:55, tbrunz <[hidden email]> wrote:

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


--------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|

Re: Class side vs instance side (variables and methods)

tbrunz
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