On Dec 13, 2005, at 9:06 PM, Adam Wolff wrote:
(Conditional includes are easy: you simply add or omit <include href=""/> or <script src=""/>. It's automatic includes that you need compiler support for. I'm sure that's what you meant, but the discussion will be simpler if it uses consistent terminology.) (Also, you can think about this as automatic includes if you start from a runtime library that only includes the _javascript_ classes, and not the components. If you start from a definition of the standard runtime that includes the standard components, then it's tree shaking, or dead code removal. This latter perspective may match what many users are more accustomed to, since they think of the library as including button, checkbox, etc. The former perspective is more useful in talking about the operation of the compiler, so that's the one I'll use.) Currently you can only include lzx classes, because the compiler uses the presence of an undefined tag to determine that a file should be included. The tags and files are listed in /WEB-INF/lps/misc/lzx-autoincludes.properties. For example, it has a line basebutton: base/basebutton.lzx which tells the compiler that a program that refers to <basebutton> should act as though it includes the line <include href=""/> unless it contains its own definition for basebutton. This is clumsy because there's just one catalog file that knows about all the components, and that is distributed with the system. There's a locality problem (lzx-autoincludes.properties refers to files in a collection of different directories that aren't particularly near to it), an extensibility problem (its part of the distribution, so you need to fork to add your own components to it), and a DRY violation (to add a component to the standard set, you need to define it in one file, and list it in another). There could be one file in each component directory, and one in the application directory, and the compiler could concatenate them all. This would address the locality and extensibility problems. It would mean that the semantics of a file would change when you moved it to another application folder, because one application's catalog could resolve <button> to an application-specific class, while another application's catalog could leave it at the default. However, this is already true of library files --- a library that is included by an file that defines <button> will get a different class than the same library included by an application that does not. This just extends that ambiguity from the set of library files (whose referents can only be determined in conjunction with the canvas file) to the set of lzx files (library files and the canvas file --- whose referents can only be determined in conjunction with the catalog file). This wouldn't address DRY. LZX could switch to the XWT strategy (I believe that MXML now does this too), where a file named myclass.lzx is assumed to contain a definition for <myclass>, and is automatically included if <myclass> is referenced. It also wouldn't address autoincludes of _javascript_-only code. The script compiler could track variable and class definitions and unknown class references, but I think there's just too much magic here, especially since the load order matters more for script code. If we were to add script file autoincludes, I would do it by implementing the 'feature' proposal on the wiki, where a developer can name the features that an application depends on, and use those feature names to decide which optional library modules to include. Is this what you meant by conditionally include library code?
Yeah, a namespace proposal has kicking around for a couple of years now and is on the wiki now: http://wiki.openlaszlo.org/Import_Statement#Namespaces. Are you volunteering to help implement it? Inner classes are harder, so I suggest going with namespaces first. |
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
