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]
