Re: libseed-list Hooking into the imports system

["Alan Knowles" <alan akbkhome com>]

It sounds alot like the autoload feature that was added to PHP.

It was only after the feature was made available that everyone realized that it was a flawed design (by that time people had already started using it...)

The partial solution was to add SPL::autoload() which does solve some of the problems..

for seed it might be that we have something like

imports.autoloader.register('xxx', function(args) {....});
or
imports.autoloader.register('xxx', imports.xxx.importer);

ZZZ = imports.autoloader.xxx.zzzz

That should give you the syntax you are after, without making it too confusing, along with enabling multiple handlers to be defined..

autoloader could easily be implemented in a very simple module...

Regards
Alan



 --- On 30/Jun/2010, Jonatan Liljedahl wrote: 
> 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