Thank you for the answer. I have indeed misunderstood what you said, so I am now looking forward to using your lightweight solution.
From my experience on OpenLaszlo so far, I loved it because it is indeed very quick forward, but as I started to want more, it could become very complex even for "simple" things like having different skins for an application. I understand the will to keep the language simple, but with a simple language, it can be difficult to address a little more complex aspects which would have been solved with a little more complex solution. It all depends on where you want to lead the platform, but from my point of view, many companies expect a lot from your already fantastic work, but could be disappointed if they don't meet their requirements. All the best P T Withington a écrit : > 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 > > > __________ NOD32 1.1459 (20060327) 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
