491646 - Expose js_StrictlyEqual() to consumers

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Donny Viszneki]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Build Identifier: 

It would be nice for applications embedding Spidermonkey to have linker access to js_StrictlyEqual() :)

Reproducible: Always

Comment 1

[Donny Viszneki]

Attachment: patch!

Comment 2

[timeless]

i disagree with the request (JS_FRIEND_API), but only because it's the wrong fix.

either a JS_StrictlyEquals should be created or a JS_SomethingEquals should be which provides a flag arg that enables access to js_StrictlyEquals.

Note that js shell uses js_StrictlyEquals which means that today you can't build js shell against js lib (I had a patch which let me build js shell against the library a while ago, clearly it doesn't anymore as I haven't provided that method).

Comment 3

[Brendan Eich [:brendan]]

Let's make a public API. Cc'ing folks one of whom should take this bug. Thanks,

/be

Comment 4

[Brendan Eich [:brendan]]

Forgot to thank Donny for the bug and patch -- thanks!

/be

Comment 5

[Donny Viszneki]

Attachment: a real patch

Until there is a proper API, it would be nice for this patch to be applied :)

Comment 6

[Donny Viszneki]

Comment on attachment 377007 [details] [diff] [review]
a real patch

This just adds JS_FRIEND_API to js_StrictlyEqual()

Comment 7

[Jason Orendorff [:jorendorff]]

Attachment: v1

Well, we might as well make it official in that case.

This API depends on === being infallible. If desired I could change the signature to,

  JSBool JS_StrictlyEqual(JSContext *cs, jsval v1, jsval v2, JSBool *result);

with the return value indicating success or failure, rather than === or !==.  It's nice to think that === will be infallible forever, but who knows?  Operator overloading in ES Harmony?

Comment 8

[Brendan Eich [:brendan]]

=== and !== are infallible, this is important. Although past operator proposals have included these among the operators that could be defined by user types, I'm skeptical anything like those proposals will fly in Harmony.

We should keep the signature infallible and bet on this. If we lose, API change!

/be

Comment 9

[Jason Orendorff [:jorendorff]]

http://hg.mozilla.org/tracemonkey/rev/2e1bbcf8a13e

Comment 10

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/2e1bbcf8a13e