Sounds reasonable. What is the impact of having a (comparatively)
large number of classes?
re: Flex and nested views.... I thought they did more or less the same
thing we did; i.e., compile it into script that constructs the views.
what is the specific difference?
On Feb 13, 2008, at 2:56 PM, Henry Minsky wrote:
Just wanted to add that we've considered that declaring a view which
declares any methods (or constraints)
will need to be compiled into a singleton class, and an instance of
it will be that view.
It the case of a view which just defines some new attributes, we
might be able to get away with just passing those
attributes in at runtime and setting them as properties on the
instance, as long as it's a dynamic class. But anything with
constraints
or methods or setters will need to have a class of its own.
side note: we don't want to go down the route that Flex apparently
did of compiling the view/class children
tree into script code, cuz then you might blow out the stack for
deeply nested layouts! I think we're better off leaving
that as a nested list?
On Wed, Feb 13, 2008 at 5:42 PM, P T Withington <[EMAIL PROTECTED]> 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]
