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 <[email protected]>: > 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: [email protected] > [mailto:[email protected]] On Behalf Of Steve > Wirts > Sent: Thursday, May 14, 2009 12:13 PM > To: [email protected] > 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 > <[email protected]> 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 >> [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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
