On 4/24/12 10:04 AM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> Hi,
>
>> There is no guarantee of instantiation order in MXML.
> I'm think there's is a defined order for containers and their children to be
> instantiated (ie parent before children) and my (limited) understanding was
> that children are created in order that they are listed in their container.
>
> Can you explain the issue is here in a bit more detail? Something to do with
> repeaters or datagroups?
There is certainly an order today for children in a container, but I don't
think it has been documented and I wouldn't want to guarantee it if it
hasn't. It is further complicated by depth and states.
I'm pretty sure the order of instantiation of things in fx:Declarations vs
display object children is different from the order of non-display object
children vs display object children in Flex 3. Again, I would not want to
guarantee it. There might be startup time optimizations to be gained by
changing the order/timing.
>
>> That's one of the reasons binding is "slow". It evaluates expressions often
>> just in case some
>> portion of the expression suddenly becomes available.
> For this patch (as supplied) that wouldn't be an issue as the expression would
> only be evaluated once right?
My point is that there is no way to guarantee the value of the expression at
the time of evaluation. We'll get puzzled users where the value is assigned
as null, but when looking in the debugger a short while later it won't be
null.
>
> I think it would be possible to also force an update (if you were having an
> issue) by calling executeBindings? (Not tried)
Maybe, but if the evaluation causes a change in the value of some other
expression you will still have problems.
>
> It's possible to run into timing issues with binding at the moment but it's
> fairly rare. I'm not sure this would increase the risk of that.
Supposedly, the binding subsystem evaluates often enough that there is no
risk of timing. This isn't true for developer-created bindings using
fx:Binding. Again, for constant expressions, there is little chance for
timing issues, but for a complex network of bindings to variable expressions
I think you are asking for trouble.
>
> Binding had been extended in a similar before with 2 way binding:
> <mx:TextInput id="t1" text="@{t2.text}"/>
>
> So I feel the syntax makes sense at least.
Yes, I don't have a problem with the proposed syntax.
>
> Perhaps some idea of code size/performance gain would give a clearer idea if
> this is a good path to take?
Optimizing for constant expressions is a good thing, but I still think it
can be done without a syntax change. I believe the compiler knows enough
about the parts of an expression to rule that all parts are constants or
literals.
Optimizing for read-once variable expressions just sounds dangerous to me.
I would not want to bake that into the compiler and invite people into a
trap.
One way to find out how such a thing would work in the real world without
changing the compiler is to create a custom helper class that does
essentially the same thing. Folks can then try out using a SetOnceBinding
class and we'll see how often folks get burned by it. I was looking into
other specific binding helper classes to optimize bindings for itemrenderers
and skins when 11/11 hit.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
