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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
