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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
