On May 9, 2016, at 6:14 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 5/9/16, 12:00 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> >> On May 9, 2016, at 8:10 AM, Alex Harui <aha...@adobe.com> wrote: >> >>> >>> >>> On 5/8/16, 1:18 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> I’m still having trouble with the spec, though. The spec has the >>>> following in [[Append]]: >>>> >>>> 3. If Type(V) is XMLList, >>>> a. Let x.[[TargetObject]] = V.[[TargetObject]] >>>> b. Let x.[[TargetProperty]] = V.[[TargetProperty]] >>>> c. Let n = V.[[Length]] >>>> d. If n == 0, Return >>>> e. For j = 0 to V.[[Length]]-1, let x[i + j] = V[j] >>>> >>>> Step e uses bracket assignment to the XMList of the values in the >>>> right-hand object. As I understand it, bracket assignment inserts the >>>> object into the target object as well. I think that’s what it says in >>>> [[Put]], but I’m not sure. Of course, with my understanding, a and b >>>> should be after step e. So, I’m somewhat confused there... >>> >>> Can you be more specific about what text makes you think the bracket >>> assignment inserts into the targetObject? I'd say that other parts of >>> the >>> spec are more explicit about calling [[Put]] and other methods and that >>> bracket syntax is just assigning values to the internal object for XML >>> and >>> XMLList. >> >> My assumption is that bracket assignment calls [[Put]]. > > 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. In the other places where [[TargetObject]] gets assigned I moved it to the end of the process as well to prevent double assignment. (Which is what I’d do here as well.) Practically, it works and seems to be how it works in Flash, but I don’t see that in the spec. > >> >>>> >>>> Either way, I think we need to add a plus() method to XML and XMLList >>>> which does “the right thing” as described by 11.4.1 in the spec. >>>> >>>> I’m also not sure every case of addition is being handled correctly: >>>> >>>> 1. Number + XML/XMLList >>>> 2. XML/XMLList + Number >>>> 3. String + XML/XMLList >>>> 4. XML/XMLList + String >>>> 5. XML/XMLList + XML/XMLList >>> >>> Well, concat() is currently what is output. It might be only used where >>> you would want to use plus(). >> >> concat() currently modifies the original XMLList. We need a method when >> returns a new one with the value added on. It should also gracefully >> handle strings and numbers. >> >> the compiler should produce the following: >> list += list4; >> should become: >> list1 = list1.plus(list4); >> >> It can be >> list1 = list1.concat(list4); >> >> My point is that the behavior of the function — whatever it’s called >> would need to change. I am using concat internally in XMLList, but I can >> change that. >> >>> But I had a not-so-nice thought: Maybe we need to rewrite our XML >>> implementation. I am feeling like we made a mistake making up our own >>> method names thinking that we understood the 'semantics' of E4x. It >>> might >>> be that we need to have you implement [[Put]] [[Append]], etc. and have >>> the compiler generate the algorithms described in the spec. >> >> I’m not sure about this. I think it’s important for bracket notation to >> “just work” without having to cross-compiling to something else. Where we >> have no choice but to require XML typing, we have no choice, but I think >> we should keep the code as close to the original as possible. > > 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. > -Alex
