Bug 37921 - API to get object class name missing from JSC
Summary: API to get object class name missing from JSC
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-21 06:55 PDT by Kartikaya Gupta
Modified: 2011-08-12 13:21 PDT (History)
4 users (show)

See Also:


Attachments
Proposed patch for JavaScriptCore/API/JSObjectRef.* (1.62 KB, patch)
2010-04-21 07:23 PDT, Kartikaya Gupta
darin: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kartikaya Gupta 2010-04-21 06:55:55 PDT
The JavaScriptCore API (i.e. stuff you get when including JavaScriptCore/JavaScript.h) doesn't provide any way to get the class name of an object. I would like to see a function added to JSObjectRef.h with this signature (or equivalent):

JS_EXPORT JSStringRef JSObjectGetClassName(JSContextRef ctx, JSObjectRef object);

which returns the class name of the object passed in.
Comment 1 Kartikaya Gupta 2010-04-21 07:23:06 PDT
Created attachment 53952 [details]
Proposed patch for JavaScriptCore/API/JSObjectRef.*
Comment 2 Nikolas Zimmermann 2010-04-21 07:32:10 PDT
Gavin, could you have a look at this patch? Highly appreciated :-)
Comment 3 Darin Adler 2010-04-21 07:53:57 PDT
Comment on attachment 53952 [details]
Proposed patch for JavaScriptCore/API/JSObjectRef.*

A class name is an internal concept in the JavaScriptCore which should not be exposed in the API. Maybe you could explain why you think this is needed, and we can help you find another solution.

Also, no change log in this change. review- for both these reasons.
Comment 4 Kartikaya Gupta 2010-04-21 09:24:38 PDT
The reason I would like it added is that I would like to be able to determine if a JSObjectRef represents a W3C DOM object. There doesn't seem to be any way to do this with the current API, so my solution was to add the JSObjectGetClassName and compare the class name to known strings (e.g. "HTMLDocument"). If there is a better way to do this I'm open to suggestions.

Also I'm not convinced that this is a JavaScriptCore-internal concept as the ECMA-262 specification does describe the [[Class]] property, which is what this is getting. In the general case the class is obtainable by calling .toString() on the object but that doesn't always work (if toString() has been overridden) and requires parsing on the returned string to extract the class name.
Comment 5 Geoffrey Garen 2010-04-21 09:46:35 PDT
> The reason I would like it added is that I would like to be able to determine
> if a JSObjectRef represents a W3C DOM object.

Can you use instanceof / JSValueIsInstanceOfConstructor?

> Also I'm not convinced that this is a JavaScriptCore-internal concept as the
> ECMA-262 specification does describe the [[Class]] property, which is what this
> is getting.

ECMA-262 does describe the [[Class]] property, but that description says "The value of a [[Class]] property is used internally" -- i.e., it's an implementation detail.
Comment 6 Kartikaya Gupta 2010-04-21 11:01:46 PDT
> Can you use instanceof / JSValueIsInstanceOfConstructor?

I did consider that but I concluded there wasn't a reliable way to get the constructor objects for the DOM classes. Doing something like JSObjectGetProperty to get window.HTMLDocument might return some HTMLDocument object overriden by a user script. I couldn't find any other way to get the constructor objects short of diving into WebCore-internal JS bindings.

> ECMA-262 does describe the [[Class]] property, but that description says
> "The value of a [[Class]] property is used internally" -- i.e., it's an
> implementation detail.

If it was really an implementation detail there would be no need to describe it in the spec. The spec even reserves some values for the [[Class]] property (e.g. Function, Array) and mandates that they be provided to the user in some cases (e.g. toString() calls) so I think it qualifies as more than just an implementation detail.
Comment 7 Gavin Barraclough 2010-04-21 12:11:00 PDT
My understanding is also that the intention behind [[CLASS]] is as a syntactic construct in defining the language, rather than as a user visible feature.  The surface where it is already exposed (toString) are causing problems in developing the language (specifically in designing a solution for proxies), which makes me think exposing this through JSC's API could again be something problematic going forwards.
Comment 8 Geoffrey Garen 2010-04-21 13:29:56 PDT
> > Can you use instanceof / JSValueIsInstanceOfConstructor?
> 
> I did consider that but I concluded there wasn't a reliable way to get the
> constructor objects for the DOM classes. Doing something like
> JSObjectGetProperty to get window.HTMLDocument might return some HTMLDocument
> object overriden by a user script.

You can pre-fetch any important constructors you're interested in before running user scripts.
Comment 9 Gavin Barraclough 2011-08-12 13:21:22 PDT
The [[Class]] property is being removed from the ES-next spec (e.g. see http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ), so we certainly don't want to expose it!