On 12/22/2010 01:02 AM, David Herman wrote:
In order for this to work you have to abandon the idea of scoped private 
identifiers.  I say: make all private identifiers scoped to the compilation 
unit.

This is the part of your suggestion that I don't like: it makes private identifiers too blunt a tool.You end up sharing with more code than you want, and when you refactor
by pulling code out of one compilation unit and into another, you share less than you want. Lexical scope is a tried-and-true mechanism for controlling sharing, and it works better than compilation units. Moreover, we don't even have a clear notion of compilation unit in the language.

It is blunt, and I'm not thrilled with it. But it might satisfy the most common use cases without preventing authors from using private names "manually" when more control is required...

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):


I do think that the conceptual clarity of requiring the sigil everywhere might well outweigh the ugliness of the sigil.

     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...

For your counter example, the original names proposal allowed for object 
literals to declare private properties, and the private name was scoped to the 
entire literal. So you'd write:

    var counter = {
       private #count: 0;
       next: function() { return this.#count++; }
       reset: function() { this.#count = 0; }
    };

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. I suppose that allowing it only within object literals would eliminate too many important use cases, however.

This is of course still strictly noisier than the original private names 
proposal, but it does have the advantage of never capturing public names by 
private declarations. It doesn't, however, address your concern about 
generativity. Personally, I like the generativity; I think it matches up with 
the use cases. But I acknowledge that it might be subtle.
Dave


Is there any syntax from the old ES4 namespace stuff that could be applied here? Instead of declaring individual private identifers, could we declare a private namespace identifier, and then use that namespace identifier as a prefix for private properties within the namespace? No sigil would be required then....

At this point, I'm just thinking out loud, so I'll call it a night.

        David


_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to