@@toStringTag spoofing for null and undefined

[Mark S. Miller]

On Tue, Jan 20, 2015 at 10:05 AM, Brendan Eich <brendan at mozilla.org> wrote:

> Domenic Denicola wrote:
>
>> From: Brendan Eich [mailto:brendan at mozilla.org]
>>
>>  >  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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150120/32cbcc2f/attachment-0001.html>