We'll have to do some more careful performance measurements to figure out what the actual affect is on application responsiveness and startup time. When we have the new class declaration stuff up will be a good time to do this.
On Wed, Feb 13, 2008 at 6:09 PM, David Temkin <[EMAIL PROTECTED]> wrote: > Your syntax proposals look good to me -- as expected. > > I do think it's critical that users be able to create sealed classes > -- that is, assuming that sealed classes do in fact deliver a real > performance benefit. > > We have compute-intensive code in "user" classes all over the place in > the apps we're building. Yes, an optimized LFC will be helpful. But it > won't deliver the benefit we are hoping to see for our application > efforts. > > This may or may not be the case for others' apps. > > - D. > > > On Feb 13, 2008, at 2:42 PM, P T Withington wrote: > > > We don't have a design for how these things will be represented in > > LZX. We're open to suggestions. Some straw proposals below: > > > > On 2008-02-13, at 16:57 EST, David Temkin wrote: > > > >> Some questions regarding classes and methods declared in LZX once > >> JS2 support is complete (well, complete enough for the purposes of > >> an initial release supporting the SWF9 runtime target). > >> > >> 1) How do method declarations look like when the parameters are > >> typed? > > > > <method name="foo" args="arg1:type1, arg2:type2, arg3:type3 = > > default3, ..."> > > > > So, just what you would type in the ()'s of a function in JS2. We > > have a plan for supporting this in JS1 runtimes as well: > http://jira.openlaszlo.org/jira/browse/LPP-5273 > > > >> 2) How do method declarations looks like when the return value is > >> typed? > > > > <method ... return="type"> > > > >> 3) How are sealed classes declared in LZX? > > > > Probably not at all initially. There are too many dynamic things > > that are done in user classes. The current plan is that the > > internal LFC classes will all be sealed, and there will be dynamic > > subclasses at the API for classes that can be extended in user code. > > > > Eventually, we may be able to tune the user class implementation > > that it can be sealed, in which case, _I_ would like that to be the > > default, and there be a modifier for keeping it dynamic: > > > >> And other questions of this sort that I've forgotten.... > > > > Can't think of any right now... > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
