Closed Bug 638312 Opened 9 years ago Closed 9 years ago

JS_IsBuiltinEvalFunction and JS_IsBuiltinFunctionConstructor

Categories

(Core :: JavaScript Engine, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: Waldo, Assigned: Waldo)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

Attached patch PatchSplinter Review
We friend-ify non-JS_ versions of these; they should just be part of the JSAPI.
Attachment #516471 - Flags: review?(gal)
Comment on attachment 516471 [details] [diff] [review]
Patch

Why IsAnyBuiltinEvalFunction but JS_IsBuiltinEvalFunction? Doesn't seem consistent. I would drop the Any.
Attachment #516471 - Flags: review?(gal) → review+
I'm adding a similar function shortly (this was actually part of that patch until I realized it'd be better in its own bug) which queries whether a value is the eval function for that other object's global, so "Any" makes the distinction between the two clearer, and hopefully prevents mistaken use of one instead of the other.
The parameterization doesn't allow for IsBuiltinEvalFunction to mean "for only this global object", so the Any is unnecessary. It reads awkwardly too. Plus it is overlong. How about penalizing the name of the function that does take a global instead? Then API and internal names line up.

/be
I was going to "penalize" both.  If both are explicit, then neither can mislead or be accidentally used, as it seems to me a JSFunction*-taking version potentially could depending on what variables the developer needing something like it had available to him.  But I don't care enough to get in yet another argument right now, over this, so I changed it.

http://hg.mozilla.org/tracemonkey/rev/52d5eb37b0a7
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/52d5eb37b0a7
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.