Though I really like the idea of keeping LFC and runtime objects out of harms way, it has been quite valuable at times to overwrite LFC elements and access the Flash API directly. In many of the large projects I've worked on, some amount of LFC overwriting has made the project more successful.
What would be the procedure for accessing the Flash API from LZX with the implementation of modules? Would direct modification of the LFC be required? -chrisk On Mar 21, 2006, at 12:42 PM, P T Withington wrote: > 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 _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
