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...
