On Tue, Jan 20, 2015 at 10:05 AM, Brendan Eich <[email protected]> wrote:
> Domenic Denicola wrote: > >> From: Brendan Eich [mailto:[email protected]] >> >> > Can we get a leg up, rather than wait for a f2f? This thread seems >>> fine for further discussion and simplifying proposals. >>> >> >> Well, to be clear, I'd prefer we not change anything at all. It's too >> late to be tweaking something that's been set in the spec for a very long >> time now. >> >> But it appears that we have some relitigation on this particular topic >> [on the agenda anyway][1]: >> > > Toxic terms like "relitigation", heard it from from RealAlexRussell and it > sucked then too, are out of line -- we are not lawyers. Also, new TC39 rep > Jordan Harband of Twitter raised this at the last meeting, asked Allen > about working on it, got a green light. > > > @@toStringTag (rationales) (Jordan Harband) >>> > >>> > - Missing unspoofable builtin values (Math, JSON, Object): spec bug >>> > - Should built-in @@toStringTag values have { configurable: false }? >>> > - Should Object.prototype.toString add a prefix to all non-built-in >>> @@toStringTag values? >>> >> >> It seems the "protections" in the spec so far have given some the >> misleading impression that we want to encourage O.p.toString as an >> unspoofable [[Class]] test. (Not that [[Class]] even exists anymore!) But >> as Allen points out, that's not the idea at all. And I'm loathe to >> perpetuate that usage of them---or even the impression that they should be >> used that way. (Nominal-typing bad! >> > > That "X-typing bad!" line is not helpful. (What is this, a sports/beer > commercial?) > > Even structural typing fans such as Mark Miller have noted in their > research results the benefits of nominal types for certain use-cases. > Sometimes you need to know your implementation. This is the exception to > the rule, but it's not always and everywhere "bad!". Yes, but I would put it more positively. Nominal and Structural typing are about different things. Neither subsume the other. Nominal types are often misunderstood to be about the string-name of types or some equally non-generative notion of type, so I prefer to use the brand terminology. The classic Types are Not Sets < http://dl.acm.org/citation.cfm?doid=512927.512938>, IIRC, uses the term "trademarking" instead with the same meaning. If anyone has a link to the actual pdf, please post. > > > Especially in ES6/ES7/etc. where proxies/value types/etc. give us the >> ability to perfectly emulate the characteristics of those types!) >> > > Yes, we want to complete the MOP so nominal types are equivalent to > branded structural types, a la Modula 3, and per David Ungar's position > articulated many times over the years (I heard David say it to Tom Van > Cutsem in person at SPLASH 2011, re: Proxies not interceding fully for all > types). But we aren't there yet. > I don't understand this paragraph. Are you saying that you want a proxy to be able to intercept and emulate the brand check, while somehow preserving the integrity implied by the brand check? > > Anyway, this has little to do with getting the details of toStringTag in > the best shape we can for ES6. Perhaps Jordan will weigh in, but in any > case, I found his links and questions from the agenda helpful -- others may > too. Here they are: > > 1. https://github.com/ljharb/agendas/wiki/January-TC39-@@ > toStringTag-discussion > > 2. https://bugs.ecmascript.org/show_bug.cgi?id=3506 > > 3. Should built-in `@@toStringTag` values have `{ configurable: false }`? > > 4. Should `Object.prototype.toString` add a prefix to *all* non-built-in > `@@toStringTag` values? > > /be > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
