Re: libseed-list js extensions for native modules

> This should be made to work - It's probably going to take a bit of
> working out how to support it...

I'm trying to understand how this works, am I right that native modules create their classes with seed_create_class() (JSClassCreate()), while the Gir importer sets up an object with a 'prototype' property "by hand"?

From the JSC API docs:

"Standard JavaScript practice calls for storing function objects in prototypes, so they can be shared. The default JSClass created by JSClassCreate follows this idiom, instantiating objects with a shared, automatically generating prototype containing the class's function objects. The kJSClassAttributeNoAutomaticPrototype attribute specifies that a JSClass should not automatically generate such a prototype."

So, the question is why the prototype is not writable and if it can be made to be that. I tried this hackish function on the constructor but it didn't work:

seed_make_extendable (JSContextRef ctx, JSObjectRef object)
  JSStringRef jname = JSStringCreateWithUTF8CString ("prototype");
  JSValueRef exception = NULL;
  JSValueRef proto = JSObjectGetPrototype(ctx, object);
  if (proto)
      JSObjectSetProperty (ctx, (JSObjectRef) object, jname, proto,

  JSStringRelease (jname);
  return TRUE;

Once JSClassCreate has made the prototype, it seems to be fixed and read-only.

Perhaps one should create classes more "manually" like the Gir importer does instead of using JSClassCreate()?

Looking through the code, it's either we have to explicitly overlay
the prototype properties in the constructor, or we set the
parent_class of Context to a standard object..

parent_class can only be a JSClassRef, and it says it should be NULL for the normal Object class, which I guess it should be. Seems like JavaScriptCore has classic inherited OOP internally, and that parent_class has nothing to do with prototype. (but that all objects has Object as parent_class)

I'm not sure I understand what you mean by overlay the prototype properties..


Regarsd Alan

--- On 21/Jun/2010, Jonatan Liljedahl wrote:
Also, it should work to add methods to SomeClass.prototype in
native modules. Currently it does not:

imports.sandbox.Context.prototype.eval_file = function(fn) { var
script = {}; GLib.file_get_contents(fn,script); return
this.eval(script.contents); };

c = new imports.sandbox.Context; c.eval_file(foobar);

TypeError Result of expression 'ctx.eval_file' [undefined] is not a

It does work for GI modules, as seen in extensions/Gtk.js


Jonatan Liljedahl wrote:
The gi_importer tries to import extensions/name.js by evaluating
 "". It would be nice if this also worked
for native modules, I imagine it to be quite common that you
write a module with core parts in C and some high-level stuff in

The question is, how should this be handled regarding searchpaths

If your module is installed in /usr/local/lib/seed, then you
probably installed the extension js in
/usr/local/share/seed/extensions, and imports.extensions would be
the right thing.

But what happens if your module is installed somewhere else? It
should probably start with the same dir as the native module,
then go on with imports.searchPath, and if the file is found call
 seed_importer_handle_file() on it..

BTW, what happens if you have 'extensions' folder in more than
one search path? will search for 'foo' in all of
those or only the first match for 'extensions'? Just doing a
'imports.extensions' will of course create only one dir_importer
for that folder, hiding possible 'extensions' folders later in
the searchpath. I don't know if this is a good thing...

/Jonatan _______________________________________________ libseed-list mailing list libseed-list gnome org
_______________________________________________ libseed-list
mailing list libseed-list gnome org

_______________________________________________ libseed-list mailing
list libseed-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]