We're considering adding something like namespace support to LZX in the form of _Modules_. The current thought is that all of the LFC will move into the module `lz`, and that the application will be in a default module `user`, unless the canvas is named, in which case the canvas name will be the name of the app module. The user module will automatically _use_ all of the `lz` module, so there will be no change to applications. [Caveat: applications that overwrite LFC elements would no longer be able to do so.]
Modules are not like C++ namespaces in that you cannot access arbitrary elements of other modules except by _use_ing the other module at compile time. There is no syntax for directly addressing an element of one module from another either at compile time or run time; and currently, the only _use_ relationship will be the implicit one where every application module implicitly uses the `lz` module. (In the future, we may allow listing the elements of the module that will be imported and renaming them on import. For now, when a module is used, all of its elements are imported without renamin. This maintains backward compatibility.) Why are we doing this? This will eliminate the possibility that the LFC or user program will clobber runtime primitives, it eliminates the possibility that a user program will clobber LFC elements, and it permits the possibility of co-existing LZX apps. We believe the module model, inspired by the [Dylan module system] (http://www.gwydiondylan.org/books/dpg/db_197.html), has all the benefits of namespaces without the complexity. No new syntax needs to be introduced to the language (identifier names are all local to the module, there are no cross-module references). The access and scoping rules of modules are simple and easy to reason about at compile time -- you can't get a runtime protection error with modules. A future project will be to support user-defined modules for more fine-grained control. Your comments are solicited. _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
