Re: libseed-list js extensions for native modules

[Jonatan Liljedahl <lijon kymatica com>]

> 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:

gboolean
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,
      kJSPropertyAttributeDontEnum|kJSPropertyAttributeDontDelete,
			   &exception);
    }

  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..

/Jonatan

> 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
> >  function.
> >
> > It does work for GI modules, as seen in extensions/Gtk.js
> >
> > /Jonatan
> >
> > Jonatan Liljedahl wrote:
> > > The gi_importer tries to import extensions/name.js by evaluating
> > >  "imports.extensions.name". 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
> > > js.
> > >
> > > The question is, how should this be handled regarding searchpaths
> > > etc?
> > >
> > > 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 extensions.foo 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 
> > > http://mail.gnome.org/mailman/listinfo/libseed-list
> > _______________________________________________ libseed-list
> > mailing list libseed-list gnome org 
> > http://mail.gnome.org/mailman/listinfo/libseed-list
>
> _______________________________________________ libseed-list mailing
> list libseed-list gnome org 
> http://mail.gnome.org/mailman/listinfo/libseed-list