New private names proposal

[Allen Wirfs-Brock]

I think there are some interesting ideas to explore in both D. Flanagan's proposal and D. Herman's variations upon it.  However, they both seem to be ignoring the second primary use case that I identified: conflict-free extensions of build-in or third party objects.  While naming conventions or a sigil seems to be satisfactory to many as a way to implement "weak encapsulation".  I don't think it works for the extension case.  



On Dec 22, 2010, at 6:26 AM, David Herman wrote:

> On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
> 
>> On 12/22/2010 01:02 AM, David Herman wrote:
>> 
>>>     function Point(x, y) {
>>>         private #x, #y;
>>>         this.#x = x;
>>>         this.#y = y;
>>>     }
>> 
>> I keep seeing this basic constructor example.  But isn't this the case that Oliver raised of private being over generative?  Those private names have been generated and discarded, and those two fields can never be read again...
> 
> Oops, I left out the ellipses:
> 
>     function Point(x, y) {
>         private #x, #y;
>         this.#x = x;
>         this.#y = y;
>         ...
>     }
> 
> Of course, if you wanted to extend the scope further, you could lift it out of the constructor.
> 
> As for the complaint of it being over-generative, that's mitigated in this case by the sigil. For example, if you wrote:
> 
>     function Point(x, y) {
>         private #x, #y;
>         this.#x = x;
>         this.#y = y;
>     }
>     Point.prototype = {
>         ... #x ... #y ...
>     };
> 
> you'd get a compile-time error since #x and #y aren't in scope. Unless, of course, they are already in scope as another private, although I'd expect this kind of thing to be a bit rarer than variable scope errors since I would guess private names wouldn't be nested and repurposed as often as variables -- that's just a guess; it's hard to be sure.
> 
> Also, you can only take the "but if you do it wrong, it doesn't work" arguments so far. After all, the generativity is by design. The question is whether that design will be too surprising and confusing. We shouldn't make JS too complicated or baroque, but we shouldn't nix an idea based on assuming too little of programmers. IOW, I think the "too complicated" criticism should be used with competent programmers in mind.
> 
> Anyway, I'm also just thinking out loud. :)
> 
>> I like private as a keyword in object literals: it doesn't seem any more confusing than get and set in literals. I don't like seeing it in functions though: there it looks like a kind of var and const analog.
> 
> Isn't this less the case when what follows the keyword isn't an ordinary identifier, i.e., has the sigil?
> 
>> Is there any syntax from the old ES4 namespace stuff that could be applied here?
> 
> An interesting thought, but I'm skeptical -- ES4 namespaces are pretty dis-Harmonious, and for good reason: there be dragons. :)
> 
> Dave
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101222/fcf098e0/attachment-0001.html>