Object.eq is ready for discussion
Mark S. Miller
erights at google.com
Mon Sep 6 09:51:04 PDT 2010
On Mon, Sep 6, 2010 at 12:30 PM, Jeff Walden
<jwalden+es at mit.edu<jwalden%2Bes at mit.edu>
> On 09/05/2010 08:31 PM, Maciej Stachowiak wrote:
>> The strawman has a note where I suggested matching "hashcode" with
>>> "identity" as the method name. If nothing else, the name length and lack of
>>> hackerly abbreviation recommend it. Comments?
>> I would expect a function named "identity" to be a function of one
>> argument that returns it unmodified, rather than a two-argument predicate
>> that implements an equivalence relation. "eq" seems like an ok name. "egal"
>> will probably seem more mysterious than "eq".
> Object.identical seems to imply the right things,
I think Object.identical is great. It is short enough. For those perturbed
by "freakishly short names"[*] it is long enough. It is even more clearly
distinct from the existing equality constructs than any of "eq", "egal" or
"equals". And most of all it is correct. Object.identical(x,y) implies that
x and y are observably indistinguishable. An equally accurate choice would
be "indistinguishable" but I don't like it. For one thing,
Object.indistinguishable(x,y) is too long for a construct we should
[*] I do not understand this objection. So my second choice remains
> certainly better than Object.identity. To the extent I want to get
> involved in this paint job, I think this is the best shade I've considered.
> Object.equals is reasonable, although as I assume people read (=)== as
> (strictly) equals, reusing the "equals" name seems like a mistake to me, if
> potentially one of small import (or not, I don't have much faith in my
> ability to predict this future, so would play it safe and avoid the name).
> Object.eq, put bluntly, is obthcure.
> Object.egal would just be confusing for ECMAScript.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss