Tim vs. Accessors

Ron Teitelbaum Ron at USMedRec.com
Tue Oct 9 01:39:25 UTC 2007


Hi All,

I knew I shouldn't have said anything.  Tim has a very good point about
instVar references.  Squeak tools are very cool and I was very pleased to
find out how easy it was to find ivar references.  It's still something else
that has to be checked (read as could be missed).  

I still haven't changed my mind; good programming doesn't come from the lack
of accessors and mutators.  Neither does the presence of accessors and
mutators mean bad programming.  I'm not even sure I agree that having
accessors and mutators enables bad programming.  Their presence is not an
invitation to use them just as having a method is not an invitation to use
it either.  Sure you can chain yourself into a mess and do many many bad
things with accessors and mutators but you shouldn't do those things and
there is no replacement for talent and experience.

I think the best way to solve this argument once and for all is for us to
agree that accessors and mutators should be placed on all ivars, but that we
should also thoroughly document them in both the methods and the class
comments.  Oh and to all agree not to program badly!  How's that? 

:)  

Ron Teitelbaum

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of tim Rowledge
> Sent: Monday, October 08, 2007 4:19 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Tim vs. Accessors
> 
> 
> On 8-Oct-07, at 12:06 PM, Steven W Riggins wrote:
> 
> >
> > On Oct 8, 2007, at 2:27 AM, Michael Rueger wrote:
> >
> >> And for me using accessors even for local inst vars is enforcing
> >> ecapsulation, not the other way round.
> >
> > This is where I agree with Michael.  Sure ok you can find people
> > touching inst vars with a tool, but really, IF performance were no
> > issue, only one place should touch the instance variable.
> 
> I don't so much disagree as don't understand how you can make that
> assertion.
> 
> As soon as you have a method that simply returns an instvar you have
> opened up access to anyone. Until and unless someone comes up with a
> good way of
> a) specifying and
> b) enforcing
> privacy then that is simply the way it is. An instvar is hidden
> except for code written in the relevant class and subclasses - that's
> what I  would consider encapsulation. Smalltalk tools can trivially
> find you all the places where that instvar is referenced or written
> to; what other languages do is so irrelevant it's barely worth
> considering. They're not of any interest at all here.
> 
> A long time ago there was a proposal for 'Modular Smalltalk'
> originally developed by the Tektronix Smalltalk folks; as I recall
> they argued that it would be good exclusively to use messages to
> access instvars, to the point that defining such a method pretty much
> defined the existence of the instvar. I can't remember if there was
> any accompanying privacy model to contain the subsequently loosed
> disencapsulation genie. (Nasty chap; bad breath, loud shirts, odious
> opinions, nasty piggy eyes, flatulent, insistent)
> 
> If - and only if - we had a sensible message privacy model could I
> agree with such a system. What would be much more useful than arguing
> about trivia would be trying to define such a system and then maybe
> implement it. I shall now offer a few thoughts on what private
> messages should do..
> 
> Class to instance
> I suggest that there needs to be a form of privacy that allows a
> class to send a message to an instance. This would be to protect
> instance initialisation methods. I suspect that it ought to be
> defined as allowing the instance to receive a message from any class
> in its inheritance tree rather than only from its actual class
> object. And yes I can already see some jerk writing the logical
> equivalent of instVarAt:put: in Object class so that they can abuse
> this form of privacy. Run fast, run far, little jerk, I'm coming for
> you on the back of the dragon on doom.
> 
> Instance to instance
> I think most privacy is likely to be of the "this should only be sent
> by me to myself" type. There might be an argument for a form that
> allows for one instance of a class to send messages to another
> instance of the same class for the purpose of copying?
> 
> Privacy violation
> What should happen? An exception? A resumable one? Core dump?
> 
> Implementation
> I can't think of any way of doing this statically outside a few
> special cases where the selector is only used for a private method
> and so the compiler can trivially spot when it is out of limits.
> Since there is absolutely no reason that #fooble:bar: should not be
> private in one class and public in another, I doubt that would be a
> very useful case.
> At runtime it seems we would need to check the flag of the method in
> some efficient manner (like a prim number perhaps) and then check for
> the sender to see if it meets the requirements.
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: HALT: No-Op
> 
> 





More information about the Squeak-dev mailing list