2010/10/27 Brendan Eich <[email protected]>: > On Oct 27, 2010, at 4:12 PM, P T Withington wrote: > > On 2010-10-27, at 17:09, Brendan Eich wrote: > > JS will never be as simple as Self, but with proxies and value types based > on them, it seems we might have get very close to the "right" answer to > David's question. > > 2p. from the Dylan POV: Dylan only had equality and identity (thinking Lisp > had just way too many equivalences). Dylan's MOP let you override (the > equivalent of) `new` and `==`, but not `===`. If you wanted value objects > that were indistinguishable, you wrote a `new` implementation that always > returned the identical object for parameters that would otherwise create > `==` values (using a weak-key table). If you only cared about equality, you > wrote a `==` method that implemented your equality test. You chose based on > whether you expected to do more constructing or more comparing. > > We talked about this during the decimal discussions in past TC39 meetings, > but hash-cons'ing decimal non-literals, esp. intermediate results in > arithmetic expression evaluations, is too expensive for hardcore numerical > performance folks. > If value types are frozen all the way down and they bottom out soon enough, > then comparing references or (if those do not match) referents, byte-wise > and deeply, should be enough for default ===. It won't handle -0m === 0m or
I can see why decimal needs to have multiple zero values since decimal values carry a precision. But can implementors of custom numeric types reuse the existing NaN value? If so, then equality only needs to be programmable to allow non-identical values to compare as equals, not to introduce any new non reflexively equal values. That might be a simpler problem to address. > 0m/0m !== 0m/0m (the NaN in decimal !== itself). At one time we thought we > could deviate from IEEE 754r on those fine points. Probably === needs to be > meta-programmable to capture all the possibilities. > Is a proxy enough of a power tool that you just have to warn the user they > must know what they are doing to use it? I.e., if you override the MOP in > some inconsistent way, it's not our fault? > > Yes, as "The Art of the Meta-Object Protocol" makes clear, you can't avoid > some sharp edges on these power tools. This is not an excuse for avoidable > unsafety of course. As noted, overriding Object.prototype.toString and other > such built-ins is a bad idea too. > Proxies, like host objects in real browsers, can produce nonsense answers, > but ES5 tightens up the language about what is legal per-spec. Proxies don't > introduce overt lack of safety, but they do mean code that thought a[i] was > never running a function (a handler trap) might have its expectations > violated. But getters and setters already rocked this boat. > This is why for-in should be metaprogrammable, or really: objecting to > for-in being programmable by a Proxy's handler iterate trap is objecting too > late and selectively, when the get and set horses (ES3R, or ES5 now), and > the rest of the harmony:proxies trap-horses (12 in total so far, excluding > iterate), have already left the barn. > Proxies are power tools. Client code that may wind up using them, even old > code written before their advent, will expect them to behave like native > objects (or "good" host objects). > This puts pressure on proxy implementors, and the JS library and client-code > ecosystem will have to sort good from bad proxy implementations. > TC39 certainly can't guarantee no bad proxies are written, except by > renouncing metaprogramming -- which we have not done in ES5 (or the "ES3R" > ES3 + reality that ES5 drew on), and will not do (in Harmony, per plans on > the wiki). Renunciation in favor of the safety of pre-1999 JS (no getters or > setters) so leaves us with only the browser implementors and their host > objects as the privileged mess-makers. From a purely Machiavellian point of > view, we want to level this playing field. > It's a scary world, but you're better off with user-level metaprogramming in > JS, compared to a world of only "kernel-level" metaprogramming in typically > C++ host object codebases. At least, I think that's TC39's position. It > certainly is mine. > /be > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
