@@toStringTag spoofing for null and undefined

Mark S. Miller erights at google.com
Tue Jan 20 16:28:59 PST 2015

On Tue, Jan 20, 2015 at 3:22 PM, David Ungar <ungar at mac.com> wrote:

> Yes, Self does have an unspoofable one, but at reflective level, not base.
> In JS syntax:
> reflect(setA) == reflect(setB)  is an unspoofable identity test. In other
> words, equality of mirrors is identity of reflectees.

Hi Dave, if your language also supports a reliable identity check, and if
you don't think that was a mistake[1], then I don't understand your
previous question:

> But on topic, the question in my mind would be: “Why does your language
support === in the first place?”

JavaScript is about as far from doing greenfield design as can be imagined,
so it is not an option to reconsider having === be the way we spell that
identity check. We have a huge corpus of code -- the web -- that we must
not break. As Crock points out, JavaScript successfully spans a greater
range of expertise, from novice to expert, than any previous language has
done at such scale. At the extremes

* Pages are created by people who don't really understand the code they are
modifying, nor the semantics of the language it is written in. They simply
keep fiddling with it until it no longer seems to be broken, and then ship
it. I used to have more mixed feelings about this until I realized that it
is *precisely* how I use LaTeX.

* Libraries are crafted by experts and extensively tested across browsers
and versions of browsers, to be linked into and composed with code of many
others, which itself likewise spans this spectrum of expertise.

The first category, by being an accidental snapshot of what worked at a
moment in time, may depend on invariants that their authors were not
consciously aware of and could not articulate, but vaguely perceived (or
not!) as a possible regularity that happened to work.

For the second category, such library code must make use of language-wide
invariants in order to successfully co-exist and intimately interact with
the wide wide range of clients into which it is linked.

Nevertheless, in successive versions of the language starting with ES3.1 we
considered breaking many invariants, we decided to break some, and did so
successfully. I agreed to those consensuses (consensi?), and in retrospect
still agree with most of those. We carefully weighed the above factors and
chose carefully which invariants to break and which to keep.

Based on the history of what === meant, I'm certain that we can't ever
break ===, even once we introduce a new (reflective if you wish) high
integrity identity test such as Object.is.

But here's an example of an invariant that we might get away with breaking:

(typeof x === typeof y && x == y) iff x === y

Specifically, I can see allowing future value types being able to override
== to implement alleged equivalence class checks less precise than equality.

[1] If you are not making those assumptions and are questioning whether a
language should have any identity check, no matter how spelled, my real
answer is

I don't think it is possible to write the escrow exchange agent of
without using reliable identity in some form. Although James Noble and
Sophia Drossopoulou have figured out how to do it without the form of
distributed identity shown in that paper. This surprised me! (Anyone
interested in how should let me know privately.)

> - David
> > On Jan 20, 2015, at 3:13 PM, Brendan Eich <brendan at mozilla.org> wrote:
> >
> > Mark S. Miller wrote:
> >>
> >>
> >>    (2) can't be meta-programmed to spoof identity. But it doesn't
> >>    leave anything like nominal types as found in many languages lying
> >>    around as an attractive nuisance (and how, in Java!).
> >>
> >>
> >> What I think I remember hearing from Tom is that Dave's main point, and
> the main argument with Tom, was precisely allowing proxies to intercede on
> === checks, in which case you wouldn't even have that as a reliable
> indicator.
> >
> > Hmm, maybe -- but does Self have a reference-identity
> equivalence-relation operator that can't be spoofed? Might help to ask
> David, but to abstract from that particular SPLASH 2011 Q&A, obviously we
> won't be enabling such fakery in JS.
> >
> > /be

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

More information about the es-discuss mailing list