On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote: > You've said this "apples to oranges" thing many times. I just don't get it.
You've read the recent messages where it became clear only [], not the . operator, was ever mooted for soft fields on the wiki. And how [] can't be a local transformation, as private lexical bindings only on the right of . or the left of : in an initialiser can be. And how private names are intended for weak encapsulation use-cases, as Allen wrote explicitly in the private_names strawman, including being able to find private names via Object.getOwnPropertyNames, e.g., to implement a clone method (so they can't possibly be implemented as soft fields). Soft fields were never equivalent to private names, or substitutable for them, even in the old strawman:names days. Anyway, strawman:private_names supersedes names, and it is more clearly an orange to the soft field apple. > 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. Not really. The frozen object extension use-case is a good one for abstractions based on weak maps. I've said that just in the previous reply but I don't see the need for syntax this soon, and (to repeat) it ought to look different from property access syntax. The "private x" declaration has no analogue in soft fields and it addresses use-cases that are inherently about syntax. Love those use-cases or hate them, they are not served by soft fields. The reflection, etc. of private names as values also has no analogue in soft fields but does arise in use cases including object inspectors, clone methods, etc. > 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. The use-cases are different and soft fields don't obviously need syntax -- and shouldn't have syntax that looks like property access. Private names are intentionally extending property access syntax because they are a new kind of property name, not a side table. These are different things. > 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? I'm skeptical we'll ever have frozen prototypes, but anyway, people can use weak maps if they need to, once weak maps are implemented. But for extending shared objects, as Prototype does? Unlikely. It'll keep doing what it has done. If it could use private names, though, while it wouldn't work with frozen prototypes, it also wouldn't need a bunch of invasive source code changes to call .get/.set or use @. A few well-placed private declarations in an outer module scope, some concatenative programming of Prototoype and its client script, and away go the conflict risks. This is all speculative, until we get weak maps out there, so it's not important to agree too far in advance. > > 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? Weak maps are harmonious. I'm saying we should not shotgun-marry some untested syntax for soft fields without lots of users clamoring for syntax instead of .get and .set. Private names need more time to be developed and user-tested, in any scenario. It's not important to triage them out of ES6 or into ES7 at this point. They're a strawman proposal, they will be implemented in a testable setting. > And please let's also agree not to prematurely standardize both kinds of > fruit. Weak maps are already harmonious. Do you mean syntax for soft fields? /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
