Re: libseed-list Hooking into the imports system

[Jonatan Liljedahl <lijon kymatica com>]

Alan Knowles wrote:
> My concern here is that this would make code very difficult to understand.
>
> Is there a way to implement this where it is an explicit behavior rather than an implicit, 
>
> Hence, when it is being used, you know from the syntax that it may be trying to do
> something magical, rather than overloading the 'reasonably'
> predictable behavior of imports.

I think that would be up to the developer, to use the notFoundHandler in 
a wise way. My plan is mostly very 'reasonable', simply to add support 
for modules written in a custom language and not having to bother if a 
module is written in C, javascript, algoscript, or imported from GIR.

But I can see other (more or less reasonable) use cases too, creating 
virtual namespaces under imports to integrate with other stuff, and I 
think it would be a very elegant feature.

> or could this not be done client side?
> eg.
>
> imports.smartloader.load('xxx');

Yes, that's almost what I do now, I have an imports.algoscript.Importer 
class with a root instance at imports.algoscript._root_importer, so that 
I can do:

zoo = imports.algoscript._root_importer._import('foo.bar.zoo');

But it means a lot of not-well-working duplication of the seed imports 
object, since I want to use it for both normal seed imports and also to 
handle directories the same was as seed imports does. (above should work 
if foo is a dir, bar a file and zoo a variable in that file)...

Also it looks very ugly, so I have created special syntactic sugar in 
algoscript to make it look like "zoo = import foo.bar.zoo".

The very nice thing with the imports object is that the properties are 
virtual (they are created/found on the fly), but that any "real" JS 
object in the chain simply takes over from there. You don't need to care 
what part is a directory, a file, or a variable in that file, or a 
member of an object in that file, etc.. This is not possible on client 
side, I'd have to write my own importer class in C for this, more or 
less duplicating everything from seed-importer.c...

But I'd really prefer to just use the existing system that's already 
there and does it the right way: then I could just have a single handler 
function, something like this:

imports.__notFoundHandler__ = function(name,dir) {
    var dirs = [dir];
    var ns;
    if(dir!=imports.searchPath[0])
        dirs = dirs.concat(imports.searchPath);
    dirs.forEach(function(d) {
        if (d == '.' && __script_path__)
            d = __script_path__;
        var f = d+'/'+name+'.as';
        if (file_exist(f)) {
            var ctx = new algoscript.Context;
            ctx.eval_file(f);
            ns = ctx.global;
            ctx.destroy();
        }
    });
    return ns;
}


> For the toString stuff, I guess that's needed only for this patch.
>
>
> BTW i'll be offline tommorow till next week, unless I can get net access...

offline, that sounds scary... ;)

see you later, thanks for the feedback!

/Jonatan

> Regards
> Alan
>
>
>  --- On 30/Jun/2010, Jonatan Liljedahl wrote: 
> > Here is a small patch that adds a feature that I'd be very happy to see.
> > It allows one to hook into the imports system by defining a handler for
> > when a module was not found. Example:
> >
> >    imports.__notFoundHandler__ = function(name, dir) {
> >      print("making "+name);
> >      return {foo:123}
> >    }
> >    f = imports.foobar;
> >    print(f.foo);
> >
> > running above file prints:
> >
> >    making foobar
> >    123
> >
> > This can be used to integrate all sorts of cool stuff with the imports
> > object. For example, the handler can iterate over imports.searchPath to
> > find n+".html" and return an object representation of the DOM tree, or
> > parsing a custom language (hmmmm ;)), or perhaps even connect to an
> > online database of modules.. x = imports.seedgems.foo; -> updates foo
> > from an online repository, etc...
> >
> > Currently it only passes the first path from seed_importer_search_dirs() 
> > as the second arg, at least this works for the case when the search is 
> > done inside a single directory, but I guess it would be better to just 
> > send the whole path GSList by converting it to a JS array. One could 
> > still work around it on the script side by merging the dir arg with 
> > imports.searchPath if dir != searchPath[0].
> >
> > BTW, this patch also adds the toString and toValue hack to 
> > seed_importer_dir_get_property() so it doesn't call the handler saying 
> > that "toString" module wasn't found, etc..
> >
> > /Jonatan
>
> _______________________________________________
> libseed-list mailing list
> libseed-list gnome org
> http://mail.gnome.org/mailman/listinfo/libseed-list