Re: libseed-list module import suggestion

["Alan Knowles" <alan akbkhome com>]

One of the points was that you might actually need to print y, to find out why the library does not work... - hence using this hiding method only works for very simple situations where you know the code will always work.

It's used by ExtJS in a few parts, and makes debugging that library a nightmare sometimes..

the phrase "Use with extreme care" comes to mind when I see it...

Regards
Alan

 --- On 17/Jun/2010, Jonatan Liljedahl wrote: 
> Here's another way, a lot simpler!
> 
> //testmodule.js
> 
> (function() {
>      var y = 42;
> 
>      this.x = 123;
>      this.f = function() { print(__script_path__+y) };
> })();
> 
> //somescript.js
> 
> t=imports.testmodule;
> t.y;     //undefined
> t.x;     //123
> t.f();   //somepath42
> 
> Jonatan Liljedahl wrote:
> > 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
> > 
> 
> _______________________________________________
> libseed-list mailing list
> libseed-list gnome org
> http://mail.gnome.org/mailman/listinfo/libseed-list