On 5/9/16, 9:44 AM, "Harbs" <harbs.li...@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. >>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'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. -Alex
