flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FlexJS][XML]appending XMLLists
Date Mon, 09 May 2016 19:52:04 GMT

On May 9, 2016, at 8:21 PM, Alex Harui <aharui@adobe.com> wrote:

> 
> 
> On 5/9/16, 9:44 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>> OK, after more reading, I think section 7.1.2 confirms your assumption.
>>> But based on the algorithm and that knowledge, do you see any issues
>>> with
>>> the Flash implementation?  Yes, it is puzzling that targetObject gets
>>> assigned before the elements are appended, but isn't Flash doing that?
>> 
>> I don’t think so. If it was, I’d think that the value would get assigned
>> agin to the XML.
> 
> Which specific scenario are you referring to?  For scenarios involving
> list4, list4 had targetObject = null so no assignment to any XML should
> occur.

I’m not expressing myself very well. Don’t worry about it. As far as I’m concerned,
if it’s working like it’s supposed to (which it is), it does not bother me that the code
does not 100% match my reading of the spec.

>>> 
>>> OK.  I think I changed my mind about this after reading 7.1.2.  If you
>>> want to rename the compiler's use of concat() to addition() or plus() it
>>> should be relatively simple.  It is in BinaryOperatorEmitter.java.  But
>>> I
>>> noticed that the regular code for + is calling copy() then concat() but
>>> +=
>>> doesn't, so the compiler could also generate a copy() first for += as
>>> well.  Right now that's a bit inconsistent as to who is in charge of the
>>> implementation, so maybe the compiler should always just call
>>> addition()/plus() and have the actual implementation make the copy.
>> 
>> Yes. I was thinking that plus() would mimic “the addition operator”
>> semantics in the spec.
>> 
>> so: foo = bar + baz would be foo = bar.plus(baz)
>> and bar += baz would become bar = bar.plus(baz)
>> 
>> and plus() would take care of creating the copy and determining whether
>> the objects are all XML or strings/numbers or what-have-you.
> 
> Feel free to make changes to BinaryOperatorEmitter and see if you can make
> it all work.

I’ll try, but the last time I did, I was not very successful. I don’t have a Java dev
setup, so I’d probably just make these edits in the text editor and run ant to build. What’s
the minimum target I need to rebuild FalconJX?

I’m also not sure I’m going to know how to do chaining.

(i.e. bar + foo + baz would need to become bar.plus(foo).plus(baz) )

> I'm not sure how much the compiler will need to be involved in "mixed
> type" expressions.  Sometimes things are all coerced to strings and
> sometimes some text gets added to XML so not sure if you can get all cases.

If the left hand XML is converted to String or Number, than we’ll have problems (although
toString() seems to work fine). Otherwise I think everything can just work.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message