es-discuss Digest, Vol 46, Issue 22

[Allen Wirfs-Brock]

On Dec 23, 2010, at 8:36 AM, thaddee yann tyl wrote:

> The private names proposal has a lot of good ideas, but their use is
> not obvious.
> The reasons I see for that are:
> The "private a;" declaration:
> * changes meaning of all obj.a in scope
> * looks like a scoped variable, not a private element of an object
> * is not generative-looking
> ... which makes it harder to understand, and use.
> 
> 
> I find that David Herman's proposal fixes those issues:
>> But your idea suggests yet another alternative worth adding to our growing pantheon. We could allow for the scoping of private names, but always require them to be prefixed by the sigil. This way there's no possibility of mixing up public and private names. So to use an earlier example from this thread (originally suggested to me by Allen):
>> 
>>  function Point(x, y) {
>>      private #x, #y;
>>      this.#x = x;
>>      this.#y = y;
>>  }
> 
> I understand that the number sign gets really heavy and annoying after
> some time. As a result, I suggest a simpler syntax, "private
> .secret;":
[snip]

There is another issue relating to the syntax chosen form accessing private names:  the refactoring impact of sigils. This has not been wide discussed on this thread although it was implicit in this:

On Dec 22, 2010, at 4:40 PM, Brendan Eich wrote:

> Now I want to make a private member of my objects, not for security but just to save my code from myself, who tends to use .x as a property name too much, and my colleague MonkeyBob, who likes to monkey-patch.
> 
> With private names, I just need to add the *** line to my constructor:
> 
> function MyConstructor(x, ...) {
>    private x; // ***
>    this.x = x;
>    ...  // closures defined that use x
> }
> 
> and I'm better off. Even if ES5's Object.getOwnPropertyNames is used by the inspector run by my other colleague ReliableFred, who needs to see x even though it is private. Fred won't do anything wrong with the value of x, but if he can't see it, he can't debug his code, which uses my code (the bug could be anywhere, or multi-factorial).

In my experience, information hiding decisions are often changed. Both during the initial develop of an object abstraction and as the abstraction evolves over the life of a system.  Any information hiding design that requires that references to hidden items be syntactically distinguished will complicate the refactoring transformations necessary to change the hidden status of such items.  that is why a sigil or new access syntax was not incorporated into my Private Names design. 

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101223/2143e26c/attachment.html>