Different reflexions: - I don't think it's a good thing to prevent us from overwriting LFC elements, if it's what you meant. Why not just have some 'final' classes, but not all? If not, it implies if we want to reuse some code, for example base classes, will we have to duplicate them? - The idea of Modules is a good thing. Grouping lz classes, why not. Java and other languages have their official set of classes. But other language don't prevent from overiding a class from anywhere else, just because it is very useful, for example if you buy components. - Suppose I want to define my own "window". If you force the compiler to load lz (containing the lz window class), I will have a duplicate class name "window" and a compiler problem. Which implies it will be impossible to have the same class names as in the lz package, which is then worse than having one or two new keywords but a lot (window, combobox, ...). - Why not use the java syntax which has proved to be very efficient and easy to use to define packages. A folder contains classes from the package it defines. Why is needed is to give a unique name to a class, based on it's package for example. For example lz.window should be one unique name and mytoppackage.mypackage.window should be another. You can add a 'package' attribute to the <class> so that we can choose between <window package="lz"> and <window package="mytoppackage.mypackage">. Having a unique class name in difficult in a big application with common names when we introduce styles, skins and things like that. So the introduction of Modules, packages, or whatever you choose is a good thing, but the main point is just to identify uniquely a class, not to add artificial problems.
Morgan P T Withington a écrit : > 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 > > __________ NOD32 1.1453 (20060321) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
