ScriptValue is now being Deprecated. It might make sense to enable new APIs directly get "any" parameters as JSC::JSValue. This may allow existing ScriptValue-based APIs to migrate to JSC::JSValue progressively and simplify the binding generator once all APIs are migrated.
Created attachment 255738 [details] Patch
Comment on attachment 255738 [details] Patch This change is OK. But our longer term plan should be to entirely remove the ScriptValue class from WebCore.
(In reply to comment #2) > Comment on attachment 255738 [details] > Patch > > This change is OK. But our longer term plan should be to entirely remove the > ScriptValue class from WebCore. I looked first at doing the whole thing. Changes seem too big for one patch. Except for IndexedDB, this might be ok as one patch. But IndexedDB is doing extensive use of ScriptValue. Plus using PassRefPtr and somehow inconsistent use of ExecState/ScriptExecutionContext, this means quite a bit of refactoring. Is there anybody actively taking care of IndexedDB I can cc? Also should there be communication to make sure future APIs use "any" as JSC::JSValue or is Deprecated namespace good enough?
Comment on attachment 255738 [details] Patch Clearing flags on attachment: 255738 Committed r186076: <http://trac.webkit.org/changeset/186076>
All reviewed patches have been landed. Closing bug.
(In reply to comment #3) > Is there anybody actively taking care of IndexedDB I can cc? Brady Eidson is doing some IndexedDB work, but not sure how much and who else would be interested. I talked to someone recently, maybe Sam, about generally tidying things up in that class. > Also should there be communication to make sure future APIs use "any" as > JSC::JSValue or is Deprecated namespace good enough? Communication or documentation would be fine. Renaming ScriptValue to DeprecatedScriptValue might be super-helpful. That worked fine back in the old days with many classes, even including one of our String classes back when we had multiple ones.