Re: libseed-list js extensions for native modules

[Jonatan Liljedahl <lijon kymatica com>]

Alan Knowles wrote:
>  --- On 29/Jun/2010, Jonatan Liljedahl wrote: 
> > Ok, so the 'extensions' folder would only be for gi_importer, but native 
> > modules should be able to have a .js wrapper in the same dir, like 
> > libseed_sandbox.so and libseed_sandbox.js?
> >
> > Then the importer should be changed to first look for libseed_NAME.so 
> > before NAME.js, and if a .so module was found then also try to eval 
> > libseed_NAME.js in the same dir. 
>
> Yeap sounds right.
>
> it seems hard to eval the script with 
> > the modules namespace as the global object (even impossible?), but 
> > perhaps one could eval the script with 'this' set to the native module 
> > namespace, or set it in some other global variable, maybe even named 
> > after the modulename?
>
> Not sure why this is needed? The Gobject libs do not need to do this, was there some reason why modules should?

No, you're right. The extension could just refer to the module as 
'imports.name', but will this be guaranteed to be the same module?

But there's still the problem with extending prototypes of classes 
created with seed_create_class(), which native modules use.

I discovered that the cairo module allows setting and getting 
imports.cairo.Context.prototype.foo, which seems to be caused by the 
class not beeing passed to the make_constructor call. But that prototype 
is not transfered to instances of Context anyhow, so it doesn't help...

/Jonatan

> Regards
> Alan
>
>
> > // libseed_sandbox.js
> > this.Context.prototype.eval_file = function(fn) {
> >      var script = {};
> >      GLib.file_get_contents(fn,script);
> >      return this.eval(script.contents);
> > };
> >
> > (then comes the problem with adding stuff to a native module class 
> > prototype, next mail...)
> >
> > /Jonatan
> >
> > Alan Knowles wrote:
> > > It would make sens that it should be able to include the higher level
> > > wrapper, I think it should only support including the js file from
> > > the same path as the extension though, to avoid to much confusion
> > > about where the wrapper was.
> > >
> > > I think the current arrangement for using the searchPath for
> > > extension finding is probably the best behaviour - closed to
> > > expected.
> > >
> > > Regards Alan
> > >
> > > --- On 21/Jun/2010, 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