WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
100292
IndexedDB: Remove IDBAny from WebKitIDL
https://bugs.webkit.org/show_bug.cgi?id=100292
Summary
IndexedDB: Remove IDBAny from WebKitIDL
Joshua Bell
Reported
2012-10-24 14:52:46 PDT
Similar to
https://bugs.webkit.org/show_bug.cgi?id=97375
IDBAny is used for attributes of type "any", and these should be replaceable with ScriptValue: IDBCursor.idl: readonly attribute IDBAny source; IDBRequest.idl: readonly attribute IDBAny source; ^^^ Another IDB type (IDBObjectStore, IDBIndex, etc) - would just need a neutral way to call ScriptValue(to[V8|JS](object)) IDBDatabase.idl: readonly attribute IDBAny version; ^^^ Number or String - would need a way to initialize ScriptValue from a number/string IDBIndex.idl: readonly attribute IDBAny keyPath; IDBObjectStore.idl: readonly attribute IDBAny keyPath; ^^^ Null, String or DOMStringList IDBRequest.idl: readonly attribute IDBAny result ^^^ All of the above, or arbitrary script value.
Attachments
Add attachment
proposed patch, testcase, etc.
Joshua Bell
Comment 1
2013-03-07 13:38:53 PST
IDBVersionChangeEvent.idl: readonly attribute IDBAny oldVersion; IDBVersionChangeEvent.idl: readonly attribute IDBAny newVersion; ^^^ Number or String ... I've been thinking about doing this in three parts: (1) Remove IntegerType/StringType/NullType/KeyPathType in favor of just ScriptValueType + the various IDB*Types (2) Reduce the IDBAny type set down to ScriptValue, and have a binding helper that does (RefPtr<T>) -> ScriptValue via toV8/toJS(). (3) Eliminate IDBAny itself IMHO #1 is valuable on its own as it removes the need to create scratch SerializedScriptValues which then are deserialized into ScriptValues. I've started #1 then abandoned this change about 5 times so far. The crux of it is that we need a ScriptExecutionContext at the point where the ScriptValue is created to get an isolate. Right now this easily done in IDBRequest but requires "dirtying" some of the other call sites - adding [CallWith=ScriptExecutionContext] IDL annotations here and there. I've toyed with several API variations, e.g.: * Require a ScriptExecutionContext to be passed to IDBAny constructors - callers need to are otherwise unchanged. * Add IDBBindingUtilities functions for stringToScriptValue(isolate, str), numberToStringValue(isolate, double), etc; IDBAny creators pass in the ScriptValue * Add constructors to ScriptValue: ScriptValue(isolate, double), ScriptValue(isolate, string), ScriptValue::null(isolate), Opinions?
Alec Flett
Comment 2
2013-03-07 14:06:03 PST
I vote for constructors on ScriptValue, the same way SerializedScriptValue already has intValue() and such.
Kentaro Hara
Comment 3
2013-03-07 16:32:51 PST
(In reply to
comment #2
)
> I vote for constructors on ScriptValue, the same way SerializedScriptValue already has intValue() and such.
Agreed.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug