New private names proposal

[David Herman]

> You've said this "apples to oranges" thing many times. I just don't get it. My comparisons at <http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields> show that these two semantics address extremely overlapping use cases. For both to be in the language, with one group (including myself) saying "use soft fields for these use cases" and another group saying the opposite, is to create conflicting conventions and the horrors of Perl's TIMTOWTDI philosophy.

Respectfully, I disagree pretty emphatically with this. JavaScript has always been a hybrid-paradigm language, and it is used to good effect in many different styles. I think it's problematic for TC39 to assume too didactic a role. We should support paradigms that can be used effectively, especially if they've been proven in practice, but we should not mandate any one particular style. Language design of course has unavoidable effects on programmer style, and this shouldn't be ignored; but this power shouldn't be taken as free license to impose discipline.

As I see it, I actually have different scenarios where I'd decide to use either weak maps or private names. For example, in Narcissus, we create proxies for the VM that hide information from the user program, and we really want them to be airtight -- in this case, I'd prefer to use a weak map to store the private data (currently, the implementation is leaky). On the flip side, when writing cooperative/collaborative code, I'd often prefer the private names approach, because the model of internal-but-hidden properties is simpler and lighter-weight. In these cases, I am not as concerned about the airtightness of the abstraction, and indeed I find some of the reflective use cases we've discussed (e.g., user-land introspection tools, general-purpose cloning operations) pretty compelling.

And ultimately, I just don't buy that TMTOWTDI is a horror. In fact, in the JS community, this aspect of the language is celebrated. We have a lively, vibrant community of programmers that experiments with idioms and shares them liberally. This is a success story of open source software!

> Do you agree at least that for the use case shown by the <http://wiki.ecmascript.org/doku.php?id=strawman:private_names#conflict-free_object_extension_using_private_names> clone example, we should all recommend soft fields, so that these extensions will not needlessly break when they encounter frozen prototypes?

IIUC, I'm afraid I don't agree. I think there will continue to be many programming scenarios where freezing is uncommon. The page says "best practice in many environments will be to freeze the primordials early." Of course, "many" is a flexible word, but it's a big bet that this will become accepted best practice in general. I'm not very good at betting on the future of the web (though I have plenty of experience suggesting that no one should listen to my predictions).

> 
> or prematurely standardize only one kind of fruit.
> 
> I don't get this either. Certainly, both are equally premature at this point. Are you saying that neither should be in ES6? 
> 
> And please let's also agree not to prematurely standardize both kinds of fruit.

Nobody's trying to rush both to standardization. But weak maps are harmonious, and soft fields are a very lightweight abstraction on top -- even if SoftField weren't in the standard, programmers would have the ability to use weak maps as soft fields. Purely as a library, I'm skeptical of the value of standardizing SoftField, but I'm open to exploring syntactic conveniences for them. I *don't*, however, think that they are a good fit for the existing object syntaxes (bracket, dot, colon-in-literals), for reasons I've stated before: the impedance mismatch between object property tables vs. side tables.

Separately from that, I believe that private names are a nice, conservative extension of the existing object model that allows for convenient and lightweight encapsulation.

All we've asked is that we not assume prima facie that we must pick a winner and stop all work on the other. That said, I don't think we should do much design work on the list or in committee meetings. The "champions" model has worked well (for example, for the proxies spec). I think Allen and others should continue working on private names, and Mark and others should continue working on soft fields. This conversation has raised helpful feedback and ideas, so now it's time for people to go back to the drawing board and do some more independent design work.

Dave

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