Re: libseed-list js extensions for native modules
- From: "Alan Knowles" <alan akbkhome com>
- To: "Jonatan Liljedahl" <j r liljedahl gmail com>
- Cc: libseed-list gnome org, libseed-list-bounces gnome org
- Subject: Re: libseed-list js extensions for native modules
- Date: Tue, 29 Jun 2010 07:28:37 +0800
--- 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?
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]