On 12/3/12 12:44 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>> If you look at the prototype, it does not use nested object literals.  I
>> was
>> unable to get them to perform as well as the data stream I am using or the
>> methods it is replacing.
>> 
> 
> So maybe we could output different code for debugging and for production?
> 
I would prefer not to, so we don't have to debug the different instantiation
paths, but no strong objections.
> 
>>> The idea would be to generate AS code from MXML that contains both the
>>> datastructures and the code fragments (<fx:Script>), keeping the line
>>> numbers (if possible).
>> It is probably possible to maintain line numbers for script blocks, but
>> what
>> are the advantages of maintaining line numbers in MXML?
>> 
> 
> For the completely declarative stuff, break points are of course not an
> argument. The only point that remains is that developers might better
> recognize their own code during debugging the more it resembles the
> original source.
> When talking about script blocks, do you mean <fx:Script> only or also
> inline event handler bodies?
> The latter should keep their line number, too.
Well, you could probably handle event handlers as well.  In theory, the data
stream can be at any line in the file.  It references the wrapped event
handlers.

> Maybe even binding expressions could generate code that you might want to
> debug (break when binding expression is re-assigned to property), but I'm
> not sure whether this is possible at all.
Binding will be interesting.  For most bindings, I'm hoping to generate data
structures as well.  Some complex bindings are an expression (e.g.
Foo="{width+somerandomfunction()}" and thus could use breakpoints.

Let's deal with this later.
> 
> -Frank-

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Reply via email to