You would still be able to access the underlying runtime directly. I should have said that the LFC will implicitly _use_ the underlying runtime, just as the user module will _use_ the lz module. Using a module gives you access to its elements, but does not let you clobber them. So just like today, you would be able to directly call the Flash interfaces. (We hope to improve conditional compilation so that you can write platform-specific code and have it automatically be selected.)
As far as patching the LFC, that would be little more difficult. You would be able to shadow an LFC element, but code within the LFC would not see this shadow. I can probably provide a loophole for this, but it could impact performance significantly on some runtimes. OTOH, we could make it easier for you to patch the LFC directly, rather than trying to do it in user code. This is probably the best solution for that -- clearly performance should be the norm and patching the LFC the exception. On 2006-03-21 21:14 EST, ChrisK wrote: > 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
