Re: libseed-list module import suggestion

[Jonatan Liljedahl <lijon kymatica com>]

Sure, that's one way to do it, but I still think that the seed importer 
should be a bit more clever and not just import everything. You 
shouldn't need to make work-arounds like below for such a basic 
functionality. In most cases, you don't want to export the entire global 
object but just selected variables.

/Jonatan

Alan Knowles wrote:
> I had quite a long play with that as well, in the end I came up with
>
> File.js
> --------------
> var _my_private_var
> var _my_private_var2
> var _my_private_var3
> ...
>
> var File = {
>    read: function() { }
>    ...
> }
> ================
>
> Usage
> File = imports.File.File;
>
> --------------------------------
>
> While not perfect (double typing the Class name..), It trades off quite a few issues..
>
> * Privates are generally private until you absolutely do not want them to be (this is very common that you need to find out what the privates contain. If you enforce hiding at runtime, it becomes very complex to test and debug).. especially since seed does not anything resembling have a debugger at present..
> eg. I can print imports.File.File._my_private_var if something wierd is happening..
>
> * It's reasonably clear what's happening.. - no hidden magic, requirement for documenting strange behavior...
>
> * enables you to do static classes, using 'this' to point to the static instance..
>
> * There is no layer of complexity meeded in the engine (always a good idea to avoid)
>
> Anyway there's a 2c viewpoint....
>
> Regards
> Alan 
>
>
>  --- On 14/Jun/2010, Jonatan Liljedahl wrote: 
> > Currently, importing another JS file imports all toplevel variables. 
> > This is not very nice, since you can't have private stuff without 
> > resorting to some hack like this:
> >
> > var _exports = (function() {
> >      var x = 123;
> >      var y = 42;
> >      var f = function() { print(x) };
> >
> >      return {
> >          y:y,
> >          f:f
> >      }
> > })();
> >
> > for(var k in _exports) {
> >      this[k] = _exports[k];
> > }
> >
> > I suggest that if a variable EXPORTS is found, only the symbols listed 
> > in it will be exported:
> >
> >    EXPORTS=[foo,bar,x,y];
> >
> > seed_importer_handle_file() would then do something like this:
> >
> >    if global.EXPORTS exist and isArray:
> >       exports = newEmptyObject()
> >       for each s in EXPORTS:
> >          exports[s] = global[s]
> >    else:
> >       exports = global
> >
> >    return exports
> >
> > One could additionally have a naming convention where symbols prefixed 
> > with underscore is ignored unless EXPORTS is defined.
> >
> > What do you think?
> >
> > /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