On Thu, Dec 23, 2010 at 11:49 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Dec 23, 2010, at 10:17 AM, Mark S. Miller wrote: > > It seems you agree enough to be exploring @ instead of ., which could >> desugar to transposed .get or .set. So perhaps more new syntax will help, >> rather than less new syntax and too much overloading of old. >> > > Rather than more or less, I was suggesting different. > > > More + new = different, but it's also more -- adding @ in addition to dot, > or @ as sigil usable after dot and left-square-bracket. We're not taking > away syntax, so the budget ceiling must rise just for @. > > > I would hate to see @ added to support soft fields in addition to "private" > and/or "#" added to support names. > > > I agree, but I'm content to let soft fields and other weak map libraries > get enough usage to warrant new syntax. The frozen AST use-case can use .get > and .set explicitly in the interim. That's why I wrote that only private > names (as currently proposed) is burdened (or blessed, or both) with new > syntax. > > > That exceeds my sense of the syntax budget we should be willing to pay. But > if it helps brainstorming not to constrain this budget early, let's continue > to try all syntax proposals on both semantics and see what the pros, cons, > and non-orthogonalities are. > > > As I wrote to David-Sarah, I'm now convinced we should *not* try mapping > syntax strawmen to both semantics. We don't even have agreement on the > syntax requirements, on #.id to get private names into runtime expressions, > reflection, and proxies. > > Plus, we have no user testbed (yet -- Narcissus is being beefed up to > prototype Harmony proposals and it can run in-browser via Zaphod -- more on > this in a bit). > > GIven weak maps in harmony, and lack of experience using them enough to > motivate syntactic sugar, I'm not in favor of adding syntax for soft fields > -- yet. Private names as proposed come with syntax as an essential part of > the proposal. > > After all this discussion it is clear to me that we should not compare > apples to oranges > 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. 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? > 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. > We're likely to end up with a Meyer lemon by mistake. > I will try to resist the temptation to expand on these colorful metaphors ;). > > /be > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
