Re: libseed-list Hooking into the imports system

[Jonatan Liljedahl <lijon kymatica com>]

I don't see how this would be solved easily..

if 'xxx' is my magic handler, then autoloader can create an object 'xxx' 
that calls my handler on get_property().. so my handler would be called 
with 'zzzz'. Let's say 'zzzz' is a folder, and I want xxx.zzzz.foo to 
load the file foo from that folder.. Nothing I can return from a 
javascript handler would allow 'foo' to be fetched unless it's already 
an existing member of 'zzzz', since there's no 
Object.prototype.__lookupProperty__ hook or similar.

Maybe one could make a generic 'dynamic object' class in C, which could 
be used recursively...

auto = new imports.dynamic.Object;
auto.get_prop = function(prop) {
  var x = my_lookup(prop,base);
//  if x is dir, return a new dynamic Object with a handler for that 
directory..
//  if x is a file, parse and return namespace..
//  etc...
};

/Jonatan

Alan Knowles wrote:
> 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