[Pharo-project] Question about PBE book by newbie, instance variables
Hi, I am very new to Pharo and Smalltalk in general. When reading through the excellent PBE book i was wondering about something on page 32. In that piece of code the LOCell class is using some instance variables from it's super classes, and i was wondering if it isn't best practice to use message to self using the accessing methods so instead of. bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16). or is good to use both or is there something i don't know (maybe it is faster to use instance vars then sending a new message and traverse the inheritance tree). regards, Gerben van de Wiel
Hi Gerben, It is really a question of style. Some people promote the use of accessors aggressively for all instance variable access. The down sides are (i) proliferation of accessor methods, and (ii) exposure of private state to other objects. If you do decide to use accessors, you should be sure to put them in a protocol called "private" to make clear that they are only intended for use by the object itself. I am curious what other people tend to do -- do you use accessors for inherited ivars, or access them directly? - on On 21 Oct 2009, at 11:45, Gerben van de Wiel wrote:
Hi,
I am very new to Pharo and Smalltalk in general. When reading through the excellent PBE book i was wondering about something on page 32. In that piece of code the LOCell class is using some instance variables from it's super classes, and i was wondering if it isn't best practice to use message to self using the accessing methods so instead of.
bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16).
or is good to use both or is there something i don't know (maybe it is faster to use instance vars then sending a new message and traverse the inheritance tree).
regards,
Gerben van de Wiel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There are two subjects here. Let me start with Oscar's query first. Since protocols in Smalltalk are a suggestion but not enforceable, I tend to avoid (ii) as much as possible and use instance variable methods with lazy initialization as much as possible to have short initialize methods. Pertaining to Gerben's question, I think an authoritative answer will be still needing: Looking at the class hierarchy from SimpleButtonMorph up, you'll see that bounds ivar is defined in Morph class and indeed there is a method Morph>>bounds:, but it is in geometry protocol (meaning is not in accessing protocol). Notice that Morph>>bounds: does not update bounds ivar directly, but rather indirectly via Morph>>extent:! So in this particular case using the accessor method would not work the same way as the code in the book (caveat emptor, I did not test this assertion!) Em 21/10/2009 10:12, Oscar Nierstrasz < oscar@iam.unibe.ch > escreveu:
Hi Gerben, It is really a question of style. Some people promote the use of accessors aggressively for all instance variable access. The down sides are (i) proliferation of accessor methods, and (ii) exposure of private state to other objects. If you do decide to use accessors, you should be sure to put them in a protocol called "private" to make clear that they are only intended for use by the object itself. I am curious what other people tend to do -- do you use accessors for inherited ivars, or access them directly? - on
On 21 Oct 2009, at 11:45, Gerben van de Wiel wrote:
Hi, I am very new to Pharo and Smalltalk in general. When reading through the excellent PBE book i was wondering about something on page 32. In that piece of code the LOCell class is using some instance variables from it's super classes, and i was wondering if it isn't best practice to use message to self using the accessing methods so instead of. bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16). or is good to use both or is there something i don't know (maybe it is faster to use instance vars then sending a new message and traverse the inheritance tree). regards, Gerben van de Wiel
Thanks again for the answers. The only thing i am a bit bothered about is the following paragraph i am reading. "Instance variables can be accessed by name in any of the instance methods of the class that defines them, and also in the methods defined in its subclasses. This means that Smalltalk instance variables are similar to protected variables in C++ and Java. However, we prefer to say that they are private, because it is considered bad style in Smalltalk to access an instance variable directly from a subclass." So this paragraph states that accessing ivars from a subclass is bad style. So the previous code example on page 32 are bad style ;). Regards, On Wed, Oct 21, 2009 at 10:01 PM, <csrabak@bol.com.br> wrote:
There are two subjects here. Let me start with Oscar's query first.
Since protocols in  Smalltalk are a suggestion but not enforceable, I tend  to avoid (ii) as much  as possible and  use  instance  variable methods with  lazy initialization as  much as  possible to have short initialize methods.
Pertaining to Gerben's question, I think an authoritative answer will be still needing:
Looking at the class hierarchy  from SimpleButtonMorph up, you'll see that  bounds ivar is  defined in Morph  class  and indeed  there is a method Morph>>bounds:, but it is in geometry protocol (meaning is not in accessing protocol).  Notice that  Morph>>bounds:  does not update bounds ivar directly, but rather indirectly via Morph>>extent:!
So in  this particular case  using the accessor method would not work the same way as the code in the book (caveat emptor, I did not test this assertion!)
Em 21/10/2009 10:12, Oscar Nierstrasz < oscar@iam.unibe.ch > escreveu:
 Hi Gerben,  It is  really a question of  style. Some people promote  the use of accessors aggressively  for all  instance variable access.  The down sides are  (i) proliferation of accessor methods,  and (ii) exposure of  private  state  to  other  objects.  If you  do  decide  to  use accessors,  you should  be sure  to put  them in  a  protocol called "private" to make  clear that they are only intended  for use by the object itself.  I am curious  what other people tend to do --  do you use accessors for inherited ivars, or access them directly?  - on
 On 21 Oct 2009, at 11:45, Gerben van de Wiel wrote:
Hi, I  am very new  to Pharo  and Smalltalk  in general.  When reading through the excellent PBE book  i was wondering about something on page 32.  In that piece  of code the  LOCell class is  using some instance variables from it's super classes, and i was wondering if it isn't best practice to  use message to self using the accessing methods so instead of. bounds  := 0@0  corner:  16@16. using  self  bounds: (0@0  corner: 16@16). or is good  to use both or is there something  i don't know (maybe it is faster  to use instance vars then sending  a new message and traverse the inheritance tree). regards, Gerben van de Wiel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
As Oscar said, it's an style question. I prefer to reference directly the instance variable in this context and don't expose private state, and also prefer to put the instance variables definition in the concrete classes and not in the abstract ones. Regards, Gabriel On Wed, Oct 21, 2009 at 6:45 AM, Gerben van de Wiel <gerben.fds@gmail.com>wrote:
Hi,
I am very new to Pharo and Smalltalk in general. When reading through the excellent PBE book i was wondering about something on page 32. In that piece of code the LOCell class is using some instance variables from it's super classes, and i was wondering if it isn't best practice to use message to self using the accessing methods so instead of.
bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16).
or is good to use both or is there something i don't know (maybe it is faster to use instance vars then sending a new message and traverse the inheritance tree).
regards,
Gerben van de Wiel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thank you very much, if i understand it correctly then instance vars in SmallTalk are "kind of" protected members in languages like Java and C#? Regards, Gerben
Yes. They key difference is that the abstraction boundary is the object, not the class. In Java, another instance of the same class can access your "private" instance variables. In Smalltalk, it cannot (unless reflection is used). - on On Oct 21, 2009, at 14:59, Gerben van de Wiel wrote:
Thank you very much, if i understand it correctly then instance vars in SmallTalk are "kind of" protected members in languages like Java and C#?
Regards, Gerben
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes. "Kind of" is the right term. In Smalltalk, an object cannot access variables of another instance of the same class. Whereas in Java this is allowed. Cheers, Alexandre On 21 Oct 2009, at 09:59, Gerben van de Wiel wrote:
Thank you very much, if i understand it correctly then instance vars in SmallTalk are "kind of" protected members in languages like Java and C#?
Regards, Gerben
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
As said, it is a matter of style. I rather use accessor methods (private mostly) because of lazy initialization. If you don't use lazy initialization, and always have valid objects in the instance variables, then you can use direct variable access or simply a message send. I also choose message sends because I can track local senders, and refactor mercilessly. But it also depends on the tool set you have, in some refactoring browsers you can see which methods "read" an inst var and also refactor inst var names on a whole hierarchy (or package). Best regards, Esteban A. Maringolo
participants (6)
-
Alexandre Bergel -
csrabak@bol.com.br -
Esteban A. Maringolo -
Gabriel Cotelli -
Gerben van de Wiel -
Oscar Nierstrasz