Hi Webkit folks - I'm Ed Rowe, and I work on the Apollo project at Apollo. I've got some questions about JavascriptCore that I'm hoping to get answered. The background is that I am trying to write a full-featured subclass of JSObject that forwards to an object in a different script engine (Flash's ActionScript in this case) and vice versa. Doing this correctly requires me to understand a number of details, some of which I admit seem somewhat pedantic. I have read all of the code for JSValue, JSObject, most of the binding code, etc. in order to figure things out on my own to the degree that it is possible. Now for the questions:
Interpreters, ExecStates, Binding --------------------------------- - ConvertValueToNPVariant() and convertValueToObjcValue(), which are used in the plugin interface binding code, both contain special logic that basically says "if wrapping up a window object, store the RootObject associated with the window object in the wrapper rather than the current RootObject". Can you tell me the purpose of this logic? I have theories, but nothing definitive. - The JavaScriptObject struct contains pointers to RootObjects. I may be missing something, but it appears to me that a JavaScriptObject struct can outlive the RootObjects that it points at, which could lead to the use of freed memory. Can this happen? - What are the rules around exceptions in the ExecState retrieved from Interpreter::globalExec()? It appears that most of the uses of it assume that there is no exception already in the ExecState when it is retrieved and clear any exception and before returning ensure that it contains no exception. Is this correct? - When a plugin is unloaded, what happens if there are existing RuntimeObjectImp instances that reference objects provided by the plugin? Is there logic to prevent a plugin from being unloaded if there are extant objects that it has provided? I haven't been able to find any code that ensures this. - There are a variety of places where exec->dynamicInterpreter()->globalObject() is called. For example, this happens in FunctionProtoFunc::callAsFunction() to handle the apply case when the this arg is NULL. In such cases, is it correct to use the global obj from the current ExecState's Interpreter as opposed to the global object at the root of the scope chain? ECMA 262 section 15.3.4.4 seems somewhat ambiguous on this subject, but my reading leads me to think that it would be more correct to pull from the scope chain. JSObject and JSValue -------------------- - Can you confirm that NULL is never an immediate JSValue and can be used to mean "no JSValue"? - Is it legal for JSObject::hasProperty(), JSObject::canPut(), or JSObject::deleteProperty() to set an exception in the passed ExecState? I cannot find any current code doing this, but I'm not sure if it is a case I need to handle or not. - Is it legal for JSObject::get() to ever return NULL? I cannot find any current code doing this, but I'm not sure if it is a case I need to handle or not. - Is it legal to set an exception in the passed ExecState in PropertySlot's GetValueFunc? I can't find any precedent in the code for a propgetter (or get itself for that matter) to throw. - Is it legal for JSObject::call() to ever return NULL? I cannot find any current code doing this, but I'm not sure if it is a case I need to handle or not. - Is the result of JSValue::type() expected to be immutable for a given JSValue instance? That is, can a particular instance return different types at different times? - Are the results of JSObject::implementsConstruct(), JSObject::implementsCall(), and JSObject::implementsHasInstance() expected to be immutable for a given JSObject instance? That is, can a particular instance return different values at different times? - The default implementation of JSObject::defaultValue() and JSObject::toPrimitive() can return an Error object if an exception occurs. This would seem to violate ECMA 262 sections 8.6.2.6 and 9.1 which state that defaultvalue() and toPrimitive() return non-Object types. Looking at some of the callers of toPrimitive(), it appears that some are not prepared to handle getting an object back. I'll file this as a bug if you guys like. - Neither JSObject::propertyIsEnumerable() nor JSObject::getPropertyAttributes() are virtual, making it impossible for a subclass to override the default behavior. Any objection to making propertyIsEnumerable() virtual, and making getPropertyAttributes() private? Thanks in advance for the help! Ed _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
