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