[Pharo-project] accessors
Hi Folks, Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible? The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter. I know this would be a lot of work but maybe it could be automated. Just tell me to shut up and go away if I'm being a nuisance. Steve :)
That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained. ? or am i just talking trash ? On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam
perhaps private accessors could go into a different category? On Thu, May 14, 2009 at 1:10 PM, Cameron Sanders < camsanders01@roadrunner.com> wrote:
That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained.
? or am i just talking trash ?
On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
perhaps private accessors could go into a different category?
Oh yeah, one could do that. (sorry, i'm in a goofy mood ;) It turns out that I nearly always implement them for my code. So I do agree that it is a good policy, in general. Such a rewrite would likely (inevitably?) introduce some bugs. It would marginally slow down some of the code. I am not involved in any core code, so I will bow out of this thread. -Cam PS: what is your debugging situation? You want to find out what all code may be modifying an object? On May 14, 2009, at 1:13 PM, Steve Wirts wrote:
On Thu, May 14, 2009 at 1:10 PM, Cameron Sanders <camsanders01@roadrunner.com
wrote:
That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained.
? or am i just talking trash ?
On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hello all, private accessors, different category - +10. Howoever, I will take this opportunity to re-re-express (sorry) my sincere hope for methods to have multiple categories. Then they become useful tags and can flag all kinds of things. Very useful. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Steve Wirts Sent: Thursday, May 14, 2009 12:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] accessors perhaps private accessors could go into a different category? On Thu, May 14, 2009 at 1:10 PM, Cameron Sanders <camsanders01@roadrunner.com<mailto:camsanders01@roadrunner.com>> wrote: That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained. ? or am i just talking trash ? On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Each time people thinking about the ways how to operate with concrete data, there are many ways in a languages which allow direct access to state. Some of them are more safe, some is not. I personally think that choosing accessors/direct ivar access is up to developer , or choose a stateless (pure functional) language which disregarding such problems completely. 2009/5/14 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Hello all,
private accessors, different category - +10. Howoever, I will take this opportunity to re-re-express (sorry) my sincere hope for methods to have multiple categories.  Then they become useful tags and can flag all kinds of things. Very useful.
Bill
________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Steve Wirts Sent: Thursday, May 14, 2009 12:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] accessors
perhaps private accessors could go into a different category?
On Thu, May 14, 2009 at 1:10 PM, Cameron Sanders <camsanders01@roadrunner.com> wrote:
That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained.
? or am i just talking trash ?
On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to  get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I kind of agree with Steve, however, it is hard to see how this will increase the quality of source code. Alexandre On 14 May 2009, at 19:10, Cameron Sanders wrote:
That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained.
? or am i just talking trash ?
On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam
_______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
It definitely is a time saver when debugging as you don't have to search for multiple occurrences of a variable being set in order to halt. I think of it as another form of encapsulation. Within a class itself all references to a variable would go through it's accessors for referencing. Kent Beck pattern #?? in his Smalltalk Best Practice Patterns book has a bit of a discussion on the merits of this approach. Maybe it's just a style thing and I should drop it though :) On Thu, May 14, 2009 at 1:14 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I kind of agree with Steve, however, it is hard to see how this will increase the quality of source code.
Alexandre
On 14 May 2009, at 19:10, Cameron Sanders wrote:
That is not always the best policy. If you provide public accessors for your private model elements (representation), the next thing you know people start using them! And then your model interfaces is constrained.
? or am i just talking trash ?
On May 14, 2009, at 12:55 PM, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
Oh, and please stick around... to draw attention away from my pesky questions.
Steve :)
-cam
_______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 14.05.2009, at 12:55, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
In general I am a fan of self-style way of not destinguishing between sends and instvar access. (like NewSpeak, Gilad has some nice blog-posts on why you want message sends for everything). But one thing can be quite problematic: performance. In Morphic, some years ago somebody did this refactoring. *all* accesses where replaced by messages sends. The problem: performance. Especially the path when accessing morphic properties added *lots* of message sends, even for the case when it was supposed to fail fast (e.g. morph-extension nil). Just removing those got us a lot of performance back when comparing 3.9 with 3.8 (these changes where later added to the OLPC image, too). Of course, this can be optimized easily in a JITed environment, but just doing it for everything in Pharo now would not be wise. In addition, one would need to think about syntax.... implicit self, yes or no? The question about debugging of course can be solved, too, by making variables real objects that one can, for example, put a break-point on... Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
On Thu, May 14, 2009 at 11:02 AM, Marcus Denker <denker@acm.org> wrote:
In general I am a fan of self-style way of not destinguishing between sends and instvar access. (like NewSpeak, Gilad has some nice blog-posts on why you want message sends for everything).
It's Newspeak, not NewSpeak. Unless you program in SmallTalk. :) The difference in Newspeak is method accessibility control (at least in principle if not in the current implementation), so representation independence doesn't come bundled with exposure of private data. --Vassili
you can always do an abstract iv refactoring when you want to debug to funnel an halt. I should say that I'm not a big fan of accessor in a language that does not have protected like semantics. Stef On May 14, 2009, at 8:02 PM, Marcus Denker wrote:
On 14.05.2009, at 12:55, Steve Wirts wrote:
Hi Folks,
Would it be inappropriate to request that an effort be made at some point to try to provide accessors for all instance/class instance variables, and try to get rid of inappropriate direct variable accessing where possible?
The "chasing variables" function is handy but seems more cumbersome than just putting a halt in a setter.
I know this would be a lot of work but maybe it could be automated.
Just tell me to shut up and go away if I'm being a nuisance.
In general I am a fan of self-style way of not destinguishing between sends and instvar access. (like NewSpeak, Gilad has some nice blog-posts on why you want message sends for everything).
But one thing can be quite problematic: performance. In Morphic, some years ago somebody did this refactoring. *all* accesses where replaced by messages sends. The problem: performance. Especially the path when accessing morphic properties added *lots* of message sends, even for the case when it was supposed to fail fast (e.g. morph-extension nil).
Just removing those got us a lot of performance back when comparing 3.9 with 3.8 (these changes where later added to the OLPC image, too).
Of course, this can be optimized easily in a JITed environment, but just doing it for everything in Pharo now would not be wise. In addition, one would need to think about syntax.... implicit self, yes or no?
The question about debugging of course can be solved, too, by making variables real objects that one can, for example, put a break-point on...
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Alexandre Bergel -
Cameron Sanders -
Igor Stasenko -
Marcus Denker -
Schwab,Wilhelm K -
Steve Wirts -
Stéphane Ducasse -
Vassili Bykov