I just tried to see if it might work, but I get an error. Obviously that’s a 
no-no...

   [java] 
/Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/projects/XML/src/main/flex/XML.as(317):
 col: 13 A return value is not allowed in a constructor.
     [java]
     [java]                             return (xml as XMLList).toXML();

> On Jul 17, 2017, at 10:28 PM, Harbs <harbs.li...@gmail.com> wrote:
> 
> I don’t think so. Write one where? How? We already have a top level XML 
> constructor.
> 
> Wouldn’t the compiler output:
> XML(myXML)
> 
> as:
> org.apache.flex.utils.Language.as(myXML,XML)?
> 
> I’m pretty sure the only way to instantiate an XML object is to use new.
> 
> Well, I just tried XML(myXMLList) and it does not call Language.as. It keeps 
> the code exactly as it was and invokes the XML constructor with the XMLList 
> as the parameter.
> 
> Of course that goes totally haywire this refers to window and none of the 
> code makes any sense. I have no idea if a constructor can return something 
> else in the middle of it. (i.e. if an XMLList is fed to the XML constructor, 
> call toXML() on the XMLList and return that.)
> 
> Harbs
> 
>> On Jul 17, 2017, at 10:08 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>> 
>> I thought we (you) already wrote one.  If not, we won't we need one?
>> 
>> -Alex
>> 
>> On 7/17/17, 12:01 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>> 
>>> Thanks for the pointer.
>>> 
>>> I changed the emitter to output indexed access. It seems to work. :-)
>>> (committed)
>>> 
>>> I’m not sure what you mean about the top level XML function. How does
>>> that work in Javascript?
>>> 
>>>> On Jul 17, 2017, at 7:47 PM, Alex Harui <aha...@adobe.com.INVALID>
>>>> wrote:
>>>> 
>>>> You can try #2 by changing ForEachEmitter.java.
>>>> 
>>>> For the general problem, we should probably just use the XML() top-level
>>>> function to "coerce" XMLList to XML.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 7/17/17, 9:23 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>> 
>>>>> That is a fourth option.
>>>>> 
>>>>> In terms of overhead, option #2 is probably cheapest and option #4 is
>>>>> probably most expensive.
>>>>> 
>>>>> What’s the difference in terms of difficulty of changing the compiler?
>>>>> 
>>>>> I agree with the general problem. It could be that we should to a
>>>>> function to XMLList toXML() (or something like that) where it would
>>>>> return an XML element if it’s a single and throw an error otherwise.
>>>>> Then
>>>>> anytime there is an XMLList assignment to XML, the compiler could add
>>>>> .toXML().
>>>>> 
>>>>> Harbs
>>>>> 
>>>>>> On Jul 17, 2017, at 7:11 PM, Alex Harui <aha...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>> 
>>>>>> IMO, this points out a generic problem where in ActionScript:
>>>>>> 
>>>>>> var harbs:XML = SomeXMLListWithOneElement;
>>>>>> 
>>>>>> would auto-coerce the XMLList to XML by grabbing the one element.  So
>>>>>> we
>>>>>> have to deal with that some day.  But there is probably a quick fix in
>>>>>> the
>>>>>> generated code for "for each" where we just generate:
>>>>>> 
>>>>>> var foo = foreachiter57_target.child(foreachiter57)[0];
>>>>>> 
>>>>>> 
>>>>>> Thoughts?
>>>>>> -Alex
>>>>>> 
>>>>>> On 7/17/17, 3:40 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>> 
>>>>>>> I discovered an issue with “for each” in the XML classes:
>>>>>>> 
>>>>>>> Currently, for each does the following:
>>>>>>> 
>>>>>>> The following AS code:
>>>>>>> 
>>>>>>> var fooList:XMLList = getFooList();
>>>>>>> for each(var foo:XML in fooList){
>>>>>>>         doSomethingWithFoo(foo);
>>>>>>> }
>>>>>>> 
>>>>>>> outputs the following JS:
>>>>>>> 
>>>>>>> var /** @type {XMLList} */ fooList = this.getFooList();
>>>>>>> var foreachiter57_target = fooList;
>>>>>>> for (var foreachiter57 in foreachiter57_target.elementNames())
>>>>>>> {
>>>>>>> var foo = foreachiter57_target.child(foreachiter57);
>>>>>>> {
>>>>>>> this.doSomethingWithFoo(foo);
>>>>>>> }}
>>>>>>> 
>>>>>>> The problem is with the line:
>>>>>>> var foo = foreachiter57_target.child(foreachiter57);
>>>>>>> 
>>>>>>> foo should be of type XML. According to the ECMA spec for E4X,
>>>>>>> XML.prototype.child and XMLList.prototype.child both ALWAYS return an
>>>>>>> XMLList and not an XML object. This is true even if the argument fed
>>>>>>> into
>>>>>>> child is an integer. So myXMLList.child(“0”) will return an XMLList
>>>>>>> with
>>>>>>> one XML element which is the first element of the original XMLList.
>>>>>>> We
>>>>>>> need the actual XML object at the specified index without the XMLList
>>>>>>> wrapper.
>>>>>>> 
>>>>>>> There are three ways I can see to fix this problem:
>>>>>>> 
>>>>>>> 1. Ignore the spec and return an XML object when the argument is an
>>>>>>> integer.
>>>>>>> 2. Change the compiler output to: var foo =
>>>>>>> foreachiter57_target[foreachiter57]; Bracket access to XMLList
>>>>>>> returns
>>>>>>> an
>>>>>>> XML object.
>>>>>>> 3. Add a new function to use instead of child() (i.e. getChild()).
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> Harbs
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to