Thanks for your comments Morgan. I will try to address them.
I think there is a misunderstanding here. The module system I am
proposing will let you overRIDE LFC definitions, just not overWRITE
them. In other words, if you define your own `window` class, your
application will see your `window` class, but other applications
(which share the LFC) will not.
I do not want to adopt the Java syntax or the C++ syntax because they
are both heavy and complex and not in the spirit LZX, which we have
tried to keep as a 'lightweight language'. I also think that the
Java and C++ syntaxes lead to 'fragile' code, because the
relationship between packages is distributed all over your source
code (although there is a Java coding style that suggests your
imports be listed at the top of each package, nothing stops you from
directly referencing other packages throughout your code).
What I am proposing today is a small step that maintains
compatibility with the existing system, and removes one flaw. The
flaw that today you can say:
<script>
var LzNode = true;
</script>
and break your entire program (because you have smashed the LFC class
that implements <node>). While it is _unlikely_ that you would
accidentally smash a definition in the LFC, because they are usually
named `Lz...` or `__Lz...`, we would like to remove even that
possibility.
The concern that ChrisK mentioned is that _sometimes_ you do want to
be able to do this, for instance to patch a broken definition in the
LFC that you are using. I think the correct solution to that issue
is that we distribute the LFC building tools in a binary form so that
it is easy for developers who are at that level to compile/edit/debug
LFC enhancements (and hopefully contribute them back to the
community). There is only a small effort involved in doing this,
since the LFC builder is just a wrapper around the compiler that is
already distributed with the server.
In a future message I will elaborate on a design for a module system
that will be available to users so that they can create their own
modules. For today, we are implementing the module infrastructure
and the 3 implicit modules: `runtime`, `lz`, and `user`.
On 2006-03-28 08:37 EST, Morgan Duchène wrote:
> 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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
