Re: libseed-list js extensions for native modules

[Jonatan Liljedahl <lijon kymatica com>]

Alan Knowles wrote:
>  
> > > 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?
>
> It should be, given our rules of 
> a) look in same folder first (which needs fixing...)
> b) look for modules first.. (which needs fixing...)

Maybe it doesn't matter if 'foo.js' will be found before 
'libseed_foo.so'? 'imports.foo' in libseed_foo.js will still refer to 
the module since the libseed_ prefix is there, and libseed_foo.js will 
not run if there was a foo.js in the searchpath.

> > But there's still the problem with extending prototypes of classes 
> > created with seed_create_class(), which native modules use.
>
> Check other mail on this..
>
> Regards
> Alan
> > 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