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]]. >> >> 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. > This would void your suggestion for adding a foreach() method. Our > current codegen expects the return of an object to iterate which is what > the E4x spec says to do. Like you mentioned there, forEach is not a good solution no-matter. > This would be a significant amount of work, but might be for the best. > > Thoughts? > -Alex >
