@@toStringTag spoofing for null and undefined

[Mark S. Miller]

[resending]

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

> Oh, the troubles with email.
>
> I’ll try again:
>
> Self stratifies things into base- and meta- level. The idea is that almost
> all code is better off sticking to base level because that promotes
> encapsulation and reuse.
> At base-level all you can do is throw messages at objects and then throw
> more messages at whatever bounces off of what the first messages return.
> So you can always substitute an object with similar behavior for another.
>
> At meta-level, you can interrogate the object to look inside; what slots
> it has, etc.
>
> This design confers reusability, eases deployment, proxying, etc. The
> paper Gilad and I wrote for OOPSLA 2004 (“Mirrors…”) explains this well.
> I gave a talk on this just last Fall at OOPSLA -- the paper  received an
> award. (Gilad was great at explaining the benefits of mirrors.)
>
> In keeping with this design, our (base-level) identity operator was just
> another message.
>
> When I asked about why JS has ===, it was a completely serious question,
> hope it didn’t sound facetious: When === was put into JS, what was the
> motivation?
> I really don’t know. I designed Self’s identity operator based on my
> perception of why ST had (and misdefined, IMO) its identity operator.
>
> I apologize for belaboring the obvious.
>
> From your response, it sounds as if == is non-overidable today. Is that
> right?
>
> - David
>
>
>
>
>
>
> On Jan 20, 2015, at 4:28 PM, Mark S. Miller <erights at google.com> wrote:
>
> 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
> http://www.erights.org/elib/equality/grant-matcher/
> http://www.erights.org/elib/equality/grant-matcher/history.html
>
> I don't think it is possible to write the escrow exchange agent of
> http://research.google.com/pubs/pub40673.html
> 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
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
>
>


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