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