Re: libseed-list module import suggestion

["Alan Knowles" <alan akbkhome com>]

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