FWIW: Clojure (the "new Lisp") uses (identical? a b)
I don't know why Rich Hickey dropped 'eq?' and went with 'identical?', but I
like it.
Cheers,
Tom
2010/9/7 Brendan Eich
> On Sep 7, 2010, at 9:34 AM, Ash Berlin wrote:
>
> > On 7 Sep 2010, at 17:18, P T Withington wrote:
> >> On 2010-09-07,
On Sep 7, 2010, at 9:34 AM, Ash Berlin wrote:
> On 7 Sep 2010, at 17:18, P T Withington wrote:
>> On 2010-09-07, at 12:02, Brendan Eich wrote:
>>
>>> 3. identical
>>
>> If I had a vote, +1
>>
>> Is there someplace that concisely explains the cost of just fixing `===` so
>> I could understand w
Oops, a word was lost by accident:
On Sep 7, 2010, at 9:41 AM, Brendan Eich wrote:
> On Sep 7, 2010, at 9:18 AM, P T Withington wrote:
>
>> On 2010-09-07, at 12:02, Brendan Eich wrote:
>>
>>> 3. identical
>>
>> If I had a vote, +1
>>
>> Is there someplace that concisely explains the cost of j
On Sep 7, 2010, at 9:18 AM, P T Withington wrote:
> On 2010-09-07, at 12:02, Brendan Eich wrote:
>
>> 3. identical
>
> If I had a vote, +1
>
> Is there someplace that concisely explains the cost of just fixing `===` so I
> could understand why that is not a choice?
The cost is hard to know wi
On 7 Sep 2010, at 17:18, P T Withington wrote:
> On 2010-09-07, at 12:02, Brendan Eich wrote:
>
>> 3. identical
>
> If I had a vote, +1
>
> Is there someplace that concisely explains the cost of just fixing `===` so I
> could understand why that is not a choice?
>
FWIW this sort of naming iss
On 2010-09-07, at 12:02, Brendan Eich wrote:
> 3. identical
If I had a vote, +1
Is there someplace that concisely explains the cost of just fixing `===` so I
could understand why that is not a choice?
___
es-discuss mailing list
es-discuss@mozilla.org
On Sep 7, 2010, at 2:39 AM, Maciej Stachowiak wrote:
> On Sep 6, 2010, at 6:01 PM, Brendan Eich wrote:
>
>> For single-parameter tests, "is" or "has" followed by a NounPhrase is indeed
>> the dominant naming convention. For a dyadic function to pair with
>> Object.hashcode, Object.identical sti
On Sep 7, 2010, at 2:10 AM, Jürg Lehni wrote:
> On 7 Sep 2010, at 02:01, Brendan Eich wrote:
>
>> It would following the verg-object-noun-phrase convention, but we have more
>> than one convention.
>>
>> Note how isNaN(x) and isFinite(x) are functions taking one parameter.
>> Whereas Object.id
I would expect compare() to return either -1, 0 or 1...
On 7 Sep 2010, at 11:58, Asen Bozhilov wrote:
> Mark S. Miller:
>> http://wiki.ecmascript.org/doku.php?id=strawman:egal
>> [...]
>> Opinions?
>
> How about:
>
> Object.compare(x, y);
>
> I think this is enough meaningful and solve the pro
Mark S. Miller:
> http://wiki.ecmascript.org/doku.php?id=strawman:egal
> [...]
> Opinions?
How about:
Object.compare(x, y);
I think this is enough meaningful and solve the problem with third
party naming collisions. I would like to see `compare' method with
more than two arguments. For example I
On 07/09/2010, at 11:39, Maciej Stachowiak wrote:
> On Sep 6, 2010, at 6:01 PM, Brendan Eich wrote:
>> On Sep 6, 2010, at 4:01 PM, Jürg Lehni wrote:
>>
>>> I agree it's a good name, but how about Object.isIdentical? Wouldn't that
>>> follow existing naming conventions more closely?
>>
>> It woul
On Sep 6, 2010, at 6:01 PM, Brendan Eich wrote:
> On Sep 6, 2010, at 4:01 PM, Jürg Lehni wrote:
>
>> I agree it's a good name, but how about Object.isIdentical? Wouldn't that
>> follow existing naming conventions more closely?
>
> It would following the verg-object-noun-phrase convention, but
On 7 Sep 2010, at 02:01, Brendan Eich wrote:
> It would following the verg-object-noun-phrase convention, but we have more
> than one convention.
>
> Note how isNaN(x) and isFinite(x) are functions taking one parameter. Whereas
> Object.identical(a, b) tests whether two values *are* identical.
With a module system it could be useful to have a module for the
'meta' functions - rather than putting more 'static class methods' on
Object. (Especially with module import - keys, values, eq etc - would
be nice to access these directly).
Though I appreciate that modules may be some way off - an
On Sep 6, 2010, at 4:01 PM, Jürg Lehni wrote:
> I agree it's a good name, but how about Object.isIdentical? Wouldn't that
> follow existing naming conventions more closely?
It would following the verg-object-noun-phrase convention, but we have more
than one convention.
Note how isNaN(x) and is
I agree it's a good name, but how about Object.isIdentical? Wouldn't that
follow existing naming conventions more closely?
Juerg
On 6 Sep 2010, at 22:45, Maciej Stachowiak wrote:
>
> On Sep 6, 2010, at 9:30 AM, Jeff Walden wrote:
>
>> On 09/05/2010 08:31 PM, Maciej Stachowiak wrote:
The
On Sep 6, 2010, at 9:30 AM, Jeff Walden wrote:
> 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. Commen
On Sep 6, 2010, at 9:51 AM, Mark S. Miller wrote:
> 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) impli
On Mon, Sep 6, 2010 at 12:30 PM, Jeff Walden
> wrote:
> 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.
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 func
On Sep 5, 2010, at 5:33 PM, Maciej Stachowiak wrote:
>
> On Sep 5, 2010, at 1:08 PM, Sam Ruby wrote:
>
>> On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich wrote:
>>>
>>> The "eq" name is freakishly short, which might up the odds of it not
>>> colliding with existing user-level extensions to Objec
On Sep 5, 2010, at 5:49 PM, Jürg Lehni wrote:
> I would propose to name it Object.equals() as opposed to the unnecessary
> short eq(), which does not seem right next to unnecessarily verbose function
> names such as Object.getOwnPropertyDescriptor()
"equals" or "equal" would be ok by me. eq is
I would propose to name it Object.equals() as opposed to the unnecessary short
eq(), which does not seem right next to unnecessarily verbose function names
such as Object.getOwnPropertyDescriptor()
Juerg
On 5 Sep 2010, at 15:40, Mark S. Miller wrote:
> http://wiki.ecmascript.org/doku.php?id=st
On Sep 5, 2010, at 1:08 PM, Sam Ruby wrote:
> On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich wrote:
>>
>> The "eq" name is freakishly short, which might up the odds of it not
>> colliding with existing user-level extensions to Object
>
> http://api.jquery.com/eq/
I don't think this would be a
On Sep 5, 2010, at 12:28 PM, Brendan Eich wrote:
> On Sep 5, 2010, at 8:28 AM, Maciej Stachowiak wrote:
>
>> Other possibilities:
>>
>> - Make Object.hashcode pair with === or == instead of Object.eq: formally
>> impossible, because neither is actually an equivalence relation. Less
>> formall
On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich wrote:
>
> The "eq" name is freakishly short, which might up the odds of it not
> colliding with existing user-level extensions to Object
http://api.jquery.com/eq/
- Sam Ruby
___
es-discuss mailing list
es-
On Sep 5, 2010, at 8:28 AM, Maciej Stachowiak wrote:
> Other possibilities:
>
> - Make Object.hashcode pair with === or == instead of Object.eq: formally
> impossible, because neither is actually an equivalence relation. Less
> formally, possible at the cost of making it impossible to use NaN a
On Sep 5, 2010, at 7:40 AM, Mark S. Miller wrote:
> http://wiki.ecmascript.org/doku.php?id=strawman:egal
>
> I have previously taken the position on this list that we should not add a
> third equality construct to JavaScript. However, it is relevant to several
> other strawmen that are likely
http://wiki.ecmascript.org/doku.php?id=strawman:egal
I have previously taken the position on this list that we should not add a
third equality construct to JavaScript. However, it is relevant to several
other strawmen that are likely to advance -- hasCode, Maps and Sets. Also,
its absence repeated
29 matches
Mail list logo
