Re: libseed-list Hooking into the imports system
- From: "Alan Knowles" <alan akbkhome com>
- To: "Jonatan Liljedahl" <j r liljedahl gmail com>
- Cc: libseed-list gnome org
- Subject: Re: libseed-list Hooking into the imports system
- Date: Wed, 30 Jun 2010 11:23:24 +0800
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]