> I'm pretty sure the binding code in the compiler knows about every token in
> the expression as it knows what the change events are for each token.
In {a.b.c} the compiler has to understand what a, b, and c resolve to, what
[Bindable] metadata there is on each one, etc. It uses the syntax tree and the
symbol table to do this.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Tuesday, April 24, 2012 3:32 PM
To: flex-dev@incubator.apache.org
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
On 4/24/12 12:07 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> Hi,
>
>> There is certainly an order today for children in a container, but I
>> don't think it has been documented
> HBox and VBox and horizontal and vertical layouts probably wouldn't
> work as expected if this changed.
I disagree. We could change the order of creation from as long as we add them
in the right order.
>
>
>> We'll get puzzled users where the value is assigned as null
> For the most common use case ie const + "const" expressions there's no issue.
Yeah, so can we just limit this optimization to constant expressions?
>
>> Optimizing for constant expressions is a good thing, but I still
>> think it can be done without a syntax change.
> You have anything you can submit or code we can look at?
I don't know the binding code that well and would recommend waiting for Falcon
to learn it, but I'm pretty sure the binding code in the compiler knows about
every token in the expression as it knows what the change events are for each
token. It knows about literals since they don't have change events. It knows
about the __NoChangeEvent__ event and I believe it generates different code for
it. And I think it already knows about constants today as well.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
