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. 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? > ++ 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.) > ++ 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). > ++ 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? _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
