About private names

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Mar 20 22:50:31 PDT 2011


On Mar 20, 2011, at 9:58 PM, Andrew Dupont wrote:

> The revision would address all my concerns — thanks. I'm all for distinguishing the static case from the dynamic case, as long as we can maintain the separation between public names and private names, and know which is which without indirection.

Can you explain why you feel this is important.  I note that it is not a characteristic of some of the most common used object oriented, even those that support explicit member visibility declarations.  more concretely, if I'm examine a line of Java code that reads like:
	this.doSomething();
there is nothing explicit that tell me the visibility of doSomeThing or that it is referring to a member that perhaps has different visibility than what is referenced by:
        that.doSomething();

Is there any evidence that this is widely know to create confusion in such languages.  I do know that some people adopt naming conventions to explicitly designate such attributes of names.  Personally, I have generally found such conventions to be a distraction. However, there is nothing that would prevent a JavaScript developer from apply such conventions to private names if they found them useful.

In general, why do I even care about such visibility at a referencing site.  At such a point I either do or don't have visibility of the property. If I do have visibility then why do I care whether or not if anyone else has visibility.  Isn't that more a concern for the definer of a property rather than a consumer?

A  separate point is that requiring such designation at every usage points makes it significantly more difficult to switch from public to private visibility or visa versa. And hence may tend to prematurely lock in such design decisions.

Allen 


More information about the es-discuss mailing list