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