327689 - Implement nsIScriptableObject

Status: RESOLVED WONTFIX

(Core :: XPCOM, enhancement)

Description

[Mark Hammond [:markh] [:mhammond]]

This bug is for patches that hope to implement nsIScriptable, as described in http://wiki.mozilla.org/New_nsIScriptable_interface.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Attachment: nsIScriptable implementation in xpcom and js

A patch implementing nsIScriptable, as described at http://wiki.mozilla.org/New_nsIScriptable_interface

* The interface nsIScriptable has been defined in xpcom/ds.  No implementation
  exists in this dir (see scriptable_base.patch for the interface and the 
  js/src/xpconnect JS implementation, and scriptable_pyxpcom.patch for the 
  python implementation)

* There is an nsIScriptableProvider implementation helper interface (defined
  in the same file).  It allows a component:

    @mozilla.org/scriptable-provider;1?id={nsIProgrammingLanguage::JAVASCRIPT}

  To return an nsIScriptable for a given implementation language.  In this 
  way, I've managed to remain completely separate from the DOM_AGNOSTIC work
  (although that work will leverage it).  This nsIScriptableProvider 
  allows me to reach into any Python or JS implemented component and get 
  an nsIScriptable around its underlying object.

  In effect, this allows Python and JS to "unwrap" each others components!

* JS implementions in (new) js/src/xpconnect/XPCnsIScriptable.cpp - the name 
  is very unfortunate - the explicit, tho ugly, use of "nsIScriptable" in 
  the name is an attempt to differentiate from nsXPCIScriptable.
  (While that name clash is unfortunate, nsIScriptable still seems a 
  reasonable name for the "public" interface - nsXPCIScriptable really
  is a private implementation interface)

  Another job of the "scriptable provider" is to convert from an nsIScriptable
  object into an nsIXPCScriptable object, to "hook" into the native |obj.foo|
  semantics provided by nsIXPCScriptable.  I'm fairly sure this isn't ideal, 
  (and indeed introduces an explicit "wrap" process that is undesirable - but 
  XPConnect is still fairly opaque to me.

* New XPCnsIScriptable.h probably should be included in xpcprivate.h, but
  currently separate for ease of review and development.

* Here is a paraphrased example of where things stand.  A "psuedo-code"
  version of a .js test that reaches into Python (the reverse also works)
---
// test_scriptable.js - run under xpcshell...
// The Python implemented xpcom component we will unwrap
var c = Components.classes["Python.TestComponent"].createInstance();

// Get an nsIScriptable from Python, which we know implements the object
var prov = Components.classes[
         "@moz.../scriptable-provider;1?id=3"].getService();
var scriptable = provider.getScriptableForObject(c);

// |scriptable| is now an object we can call nsIScriptable methods on,
// such as |getDispID| or |invoke()|.  Let's turn it into something 
// we can directly do |ob.foo| on, using the JS scriptable-provider

// This provider can take an nsIScriptable and turn it into an
// nsIXPCScriptable, which provides the |obj.foo| magic.
var jsprovider = Components.classes[
         "@moz.../scriptable-provider;1?id=2"].getService();

var ob = jsprovider.getObjectForScriptable(scriptable);
// |ob| is now something we can do |ob.foo| on, and nsIScriptable magic
// will happen.

// Get the '__class__' attribute from the Python object.
var cls = ob.__class__

// |cls| is now an nsIScriptable around a Python class
//    [xpconnect wrapped nsIScriptable @ 0x1066bb0 (native @ 0x1066ee4)]
// (sadly, we now still need to use the provider to turn
// it back into an nsIXPCScriptable - thats not desirable - more
// XPConnect integration is required!

cls = jsprovider.getObjectForScriptable(cls)
// cls now:
// [object nsIScriptable @ 0x1094a10 (native @ 0x10d7a68)]
---

  the real code is in scriptable_pyxpcom.patch at:
  extensions/pyxpcom/tests/test_scriptable.js

Apart from the horrible name of the components (XPCnsIScriptable.xxx), and 
the fact I'm pretty clueless about to best leverage XPCConnect to reuse the
existing infrastructre, I think this is on the right track.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

Attachment: Patch which implements the pyxpcom side of nsIScriptable

The pyxpcom side of the world.  See comments in previous attachment.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Attachment: Updated patch

New patch that captures recent work.  Has Python and JS happily calling each other.  Still needs some work and discussion, but uploading it to ensure a copy exists other than here!

Comment 4

[Mark Hammond [:markh] [:mhammond]]

Attachment: A functional implementation

A new patch with far more working, with both JS and Python based tests to show off the working functionality.

Comment 5

[Mark Hammond [:markh] [:mhammond]]

out of date