On Jul 10, 2006, at 9:17 AM, P T Withington wrote: > On 2006-07-09, at 21:04 EDT, Jim Grandy wrote: > >> I'm browsing through the Legals sources this afternoon, and had some >> comments: >> >> First, on the contents of WEB-INF/lps/lfc/kernel/swf. >> >> + The folder name 'swf' is imprecise, and will be confusing when we >> add a Flash 9 kernel. May I suggest 'avm2' as the most precise >> option? (AVM == Adobe Virtual Machine, AVM2 is the one used in >> Flash6-8, AVM3 is used in Flash9. The only other option that covers >> Flash7-8 is ActionScript 2, but we're targeting a runtime not a >> language.) The same argument covers WEB-INF/lps/lfc/views/platform/ >> swf, and anywhere else we are switching on kernel. > > In the compiler, we have the compile-time constants (which can be > used to dispatch compile-time conditionals), $as2 (which is true > for swf runtimes 7-9) and $as3 (which is true for swf runtime 9), > and $js1 (which is true for dhtml and orbit runtimes). > > I agree that as2 is less precise that avm2, but lean toward using a > conventional term. > I'm fine with as2, since no one but me seems to have internalized the definition of avm2/avm3. > But this all comes back to the issue we keep going around on, > whether to use conditional compilation or directory structure to > organize multi-platform support. I don't think we can be Draconian > about it. I think we should have the flexibility to use the > mechanism that is most appropriate. In particular, in this case, > it is perhaps not unreasonable to have a generic swf directory with > conditional code for swf7/8/9 or as2/3 in the files in that > directory, especially if there are only minor tweaks needed for the > swf9 support. We don't want to have platform directories that are > split but share 99% of their code, do we? > I'm pretty sure you are going to want a separate kernel, but I guess I don't know that for sure. (Why do I think so? For one thing, the swf9 kernel is written in a different language -- ActionScript 3 -- than the swf7-8 kernel. I thought the kernel sources went directly to the backend compiler? How are you going to put type declarations and so on into the kernel sources and still send them to the existing AS2 backend?)
But on the principle of the Simplest Thing that could Possibly Work, I'm happy to wait until you get that far in your investigation. >> ++ OL class dependency in one kernel is going to require the same >> dependency in all kernels, so we need a blanket policy one way or the >> other; > > I'm not sure I follow that logic. Right now the relationship > between the kernel and the LFC is that a Node has-a Sprite, so > there need not be any particular relationship between the class > system of the LFC and the class system of the kernel. The Node and > Sprite class systems are different in the current implementation, > which to me is proof that they could also be the same, and that > each platform could have its own class implementation supporting > Sprite. (It would not be unreasonable to have a 'reference' Sprite > implementation that uses Plain-Old-Javascript, or LZS + our class > substrate, or both.) > You snipped out the bit where I said, " I strongly feel that we should avoid dependencies on the OpenLaszlo class system in the kernel APIs". Note the term "APIs". I don't have a problem with using the class system internally, if that makes the most sense -- but only Henry's expedience argument really strikes me as a good justification for this. >> ++ Each kernel has to be as fast, small, and feature-full as >> possible; and > > These are competing constraints. In particular, both Henry and Max > have lamented not being able to make super calls in the current > LzSprite implementation. > > Our core class implementation is 173 lines of Javascript. That > includes traits. That implementation can actually make writing > classes more compact, because you will not have to write out each > method longhand (in exchange for some computation at runtime to > 'unpack' the more compact notation). > But it also precludes the use of a native class system, potentially trading away significant compiler optimizations. And makes it harder to incorporate non-Laszlo code into the kernel without revision. This is a long-term maintenance and optimization question. My sense is that the more we keep the kernels "native", the better chance we have of making each kernel as finely tuned as possible to the particular runtime. At a minimum, the kernel APIs need to avoid dependencies. What would you do if you decided the best kernel implementation for a given runtime was in C, or in Java, with Javascript bindings only at the API level? >> ++ In certain runtimes, maximum speed, minimum size, and particular >> features may require using native class systems or native language >> features that are incompatible with the OL class system. (For >> example, we will almost certainly want to be able to seal as much of >> the SWF9 kernel as possible, and that may require using AS3 classes >> and syntax.) > > I thought our plan of record was to make the OL class system a > Javascript2 system, to accept these declarations, and to degrade > gracefully on runtimes that cannot support or enforce the > declarations? I'm talking about the kernel implementation, not the LFC/ORL implementation. The kernels are non-portable by design -- it is the LFC/ORL that is portable and should degrade gracefully. That's why we put the compiler pass-through in place -- so that the kernels could be written as close to the (virtual) metal as possible. jim _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
