Re: libseed-list js extensions for native modules

["Alan Knowles" <alan akbkhome com>]

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

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