You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/07/17 10:40:11 UTC
[FlexJS XML] for each
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
Re: [FlexJS XML] for each
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I assume you tested this with regular Flex and not the Falcon compiler? I
> just want to verify a couple of your findings.
Be aware there are existing unresolved bugs in the Flex SDK in this area i.e. [1]
Thanks,
Justin
1. https://issues.apache.org/jira/browse/FLEX-33644
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
> On Jul 18, 2017, at 6:13 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I assume you tested this with regular Flex and not the Falcon compiler?
Yes.
> I just want to verify a couple of your findings.
>
> 1) Does passing empty string really produce an XML object with no children
> or is there a child textNode with “”?
new XML() and new XML(null) and new XML(“”) all produce identical XML objects. By default, XML seems to have a nodeKind of text. If you set properties on the XML, that changes. If you pass a string, it creates a text node with no children:
The following:
var xml7:XML = new XML();
var xml8:XML = new XML("");
var xml9:XML = new XML(null);
var xml10:XML = new XML("foo");
var xml11:XML = new XML({foo:"baz"});
trace(xml7.children().length());
trace(xml8.children().length());
trace(xml9.children().length());
trace(xml10.children().length());
trace(xml11.children().length());
trace(xml7);
trace(xml8);
trace(xml9);
trace(xml10);
trace(xml11);
Outputs:
0
0
0
0
0
foo
[object Object]
> 2) If you pass in an XMLList with one element, doesn't
>
> var harbs:XML = XML(someXMLListWithOneElement)
>
> return the one element but
>
> var harbs:XML = new XML(someXMLListWithOneElement)
>
> return a clone?
Good call.
The following code:
var xml1:XML = new XML("foo");
var xml2:XML = XML(xml1);
var xml3:XML = new XML(xml1);
trace(xml1 === xml2);
trace(xml1 === xml3);
var xml4:XMLList = new XMLList(xml1);
var xml5:XML = new XML(xml4);
var xml6:XML = XML(xml4);
trace(xml1 === xml5);
trace(xml1 === xml6);
trace(xml5 === xml6);
Outputs:
true
false
false
true
false
(“==“ outputs true for all of the above.)
>
> IMO, toXML should do what Flash does unless it is really expensive. If
> you had code that relied on Flash behavior, what would you have to do to
> rework the code to the spec?
>
I think the observed behavior is bug-prone. The documented behavior makes much more sense. I can’t think of a good reason to cast null or undefined to XML. If you really want to cast on object to a string, you can always call toString(). Fixing such code should be really easy.
In terms of implementation, it’s not really harder one way or the other.
> My 2 cents,
> -Alex
>
> On 7/18/17, 1:29 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>> Actually, it’s not really necessary to allow null and undefined to get an
>> empty XML object. The constructor can default to en empty string. So an
>> empty string could get an XML object while null and undefined could throw
>> an error.
>>
>> That might make more sense because it would likely catch more errors.
>>
>>> On Jul 18, 2017, at 11:07 AM, Harbs <ha...@gmail.com> wrote:
>>>
>>> I discovered that the documentation on the top level functions is wrong.
>>>
>>> According to the docs[1] the only valid expressions for XML and XMLList
>>> are: XML, XMLList, Boolean, Number and String. Anything else is supposed
>>> to throw an error.
>>>
>>> What actually happens is that null and undefined are simply swallowed
>>> and you get an empty XML text node object. Everything else simply has
>>> toString() called on it, so if you pass in an Object which does not have
>>> an implementation of toString(), you’ll get a text node with a value of
>>> [object Object].
>>>
>>> In my tests, new XML() and XML() behave identically.
>>>
>>> That’s not what I’d call great behavior…
>>>
>>> So the question is what to do. What I think makes sense is to make
>>> toXML() behave like the docs and new XML() behave like the observed
>>> behavior. At the least for null and undefined. There needs to be a way
>>> to instantiate an empty XML object. I’m on the fence about objects. I’m
>>> leaning toward always throwing an error if the argument is an object.
>>>
>>> Thoughts?
>>>
>>> Harbs
>>>
>>>
>>> [1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.a <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.a>
>>> dobe.com <http://dobe.com/>%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fpackage
>>> .html%23XML&data=02%7C01%7C%7C9ab55b27d96c403de2e208d4cdb7a394%7Cfa7b1b5a
>>> 7b34438794aed2c178decee1%7C0%7C0%7C636359635983774211&sdata=rxcx9eUoc%2F%
>>> 2FufMzesTKqS8fp7bdV1yQUIoPyckupXGs%3D&reserved=0()
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.ado <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.ado>
>>> be.com <http://be.com/>%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fpackage.h
>>> tml%23XML&data=02%7C01%7C%7C9ab55b27d96c403de2e208d4cdb7a394%7Cfa7b1b5a7b
>>> 34438794aed2c178decee1%7C0%7C0%7C636359635983774211&sdata=rxcx9eUoc%2F%2F
>>> ufMzesTKqS8fp7bdV1yQUIoPyckupXGs%3D&reserved=0()>
>>>
>>>> On Jul 18, 2017, at 8:20 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>
>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>> I’ll try to write these functions today.
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I assume you tested this with regular Flex and not the Falcon compiler? I
just want to verify a couple of your findings.
1) Does passing empty string really produce an XML object with no children
or is there a child textNode with ""?
2) If you pass in an XMLList with one element, doesn't
var harbs:XML = XML(someXMLListWithOneElement)
return the one element but
var harbs:XML = new XML(someXMLListWithOneElement)
return a clone?
IMO, toXML should do what Flash does unless it is really expensive. If
you had code that relied on Flash behavior, what would you have to do to
rework the code to the spec?
My 2 cents,
-Alex
On 7/18/17, 1:29 AM, "Harbs" <ha...@gmail.com> wrote:
>Actually, it’s not really necessary to allow null and undefined to get an
>empty XML object. The constructor can default to en empty string. So an
>empty string could get an XML object while null and undefined could throw
>an error.
>
>That might make more sense because it would likely catch more errors.
>
>> On Jul 18, 2017, at 11:07 AM, Harbs <ha...@gmail.com> wrote:
>>
>> I discovered that the documentation on the top level functions is wrong.
>>
>> According to the docs[1] the only valid expressions for XML and XMLList
>>are: XML, XMLList, Boolean, Number and String. Anything else is supposed
>>to throw an error.
>>
>> What actually happens is that null and undefined are simply swallowed
>>and you get an empty XML text node object. Everything else simply has
>>toString() called on it, so if you pass in an Object which does not have
>>an implementation of toString(), you’ll get a text node with a value of
>>[object Object].
>>
>> In my tests, new XML() and XML() behave identically.
>>
>> That’s not what I’d call great behavior…
>>
>> So the question is what to do. What I think makes sense is to make
>>toXML() behave like the docs and new XML() behave like the observed
>>behavior. At the least for null and undefined. There needs to be a way
>>to instantiate an empty XML object. I’m on the fence about objects. I’m
>>leaning toward always throwing an error if the argument is an object.
>>
>> Thoughts?
>>
>> Harbs
>>
>>
>>[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.a
>>dobe.com%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fpackage
>>.html%23XML&data=02%7C01%7C%7C9ab55b27d96c403de2e208d4cdb7a394%7Cfa7b1b5a
>>7b34438794aed2c178decee1%7C0%7C0%7C636359635983774211&sdata=rxcx9eUoc%2F%
>>2FufMzesTKqS8fp7bdV1yQUIoPyckupXGs%3D&reserved=0()
>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.ado
>>be.com%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fpackage.h
>>tml%23XML&data=02%7C01%7C%7C9ab55b27d96c403de2e208d4cdb7a394%7Cfa7b1b5a7b
>>34438794aed2c178decee1%7C0%7C0%7C636359635983774211&sdata=rxcx9eUoc%2F%2F
>>ufMzesTKqS8fp7bdV1yQUIoPyckupXGs%3D&reserved=0()>
>>
>>> On Jul 18, 2017, at 8:20 AM, Harbs <harbs.lists@gmail.com
>>><ma...@gmail.com>> wrote:
>>>
>>> I’ll try to write these functions today.
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
Actually, it’s not really necessary to allow null and undefined to get an empty XML object. The constructor can default to en empty string. So an empty string could get an XML object while null and undefined could throw an error.
That might make more sense because it would likely catch more errors.
> On Jul 18, 2017, at 11:07 AM, Harbs <ha...@gmail.com> wrote:
>
> I discovered that the documentation on the top level functions is wrong.
>
> According to the docs[1] the only valid expressions for XML and XMLList are: XML, XMLList, Boolean, Number and String. Anything else is supposed to throw an error.
>
> What actually happens is that null and undefined are simply swallowed and you get an empty XML text node object. Everything else simply has toString() called on it, so if you pass in an Object which does not have an implementation of toString(), you’ll get a text node with a value of [object Object].
>
> In my tests, new XML() and XML() behave identically.
>
> That’s not what I’d call great behavior…
>
> So the question is what to do. What I think makes sense is to make toXML() behave like the docs and new XML() behave like the observed behavior. At the least for null and undefined. There needs to be a way to instantiate an empty XML object. I’m on the fence about objects. I’m leaning toward always throwing an error if the argument is an object.
>
> Thoughts?
>
> Harbs
>
> [1]http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.html#XML() <http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.html#XML()>
>
>> On Jul 18, 2017, at 8:20 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> I’ll try to write these functions today.
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
I discovered that the documentation on the top level functions is wrong.
According to the docs[1] the only valid expressions for XML and XMLList are: XML, XMLList, Boolean, Number and String. Anything else is supposed to throw an error.
What actually happens is that null and undefined are simply swallowed and you get an empty XML text node object. Everything else simply has toString() called on it, so if you pass in an Object which does not have an implementation of toString(), you’ll get a text node with a value of [object Object].
In my tests, new XML() and XML() behave identically.
That’s not what I’d call great behavior…
So the question is what to do. What I think makes sense is to make toXML() behave like the docs and new XML() behave like the observed behavior. At the least for null and undefined. There needs to be a way to instantiate an empty XML object. I’m on the fence about objects. I’m leaning toward always throwing an error if the argument is an object.
Thoughts?
Harbs
[1]http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.html#XML() <http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.html#XML()>
> On Jul 18, 2017, at 8:20 AM, Harbs <ha...@gmail.com> wrote:
>
> I’ll try to write these functions today.
>
Re: [FlexJS XML] for each
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> We might keep around a Language class for things "every" app will need
> (is/as, maybe some coercions). But trace, sortOn, Vector should be PAYG.
Currently the SDK itself uses trace (including in a few core classes [1]) so unless they are removed it's likely you end up with the code for trace in you application.
Thanks,
Justin
1. https://builds.apache.org/analysis/component_issues?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#resolved=false|types=VULNERABILITY|rules=flex%3AS1951
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
We might keep around a Language class for things "every" app will need
(is/as, maybe some coercions). But trace, sortOn, Vector should be PAYG.
-Alex
On 7/17/17, 10:20 PM, "Harbs" <ha...@gmail.com> wrote:
>Another reason to not add to Language is that it would make Language
>depend on XML.
>
>I’ll try to write these functions today.
>
>I don’t mind breaking up utility classes, but the Language class will
>need changes to the compiler. It looks like it’s more than just replacing
>org.apache.flex.utils.Language with org.apache.flex.utils (or something
>like that) because the compiler needs to know when to add goog.requires
>for each of the utility functions.
>
>> On Jul 18, 2017, at 5:19 AM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> IMO, toXML() is more PAYG. We really shouldn't keep adding to Language.
>>
>> I'm going to figure out why your standalone functions like callLater,
>> assert, etc, aren't handled correctly then we should seriously think
>>about
>> finding a volunteer to break up these utility classes into utility
>> functions since that would be more PAYG.
>>
>> -Alex
>>
>> On 7/17/17, 2:55 PM, "Harbs" <harbs.lists@gmail.com
>><ma...@gmail.com>> wrote:
>>
>>> I believe you are right in Flash. Same for XMLList().
>>>
>>> I’d be happy to write the functions. Should we do a top level toXML()
>>>or
>>> Language.XML() and Language.XMLList()?
>>>
>>> The latter seems to fit the pattern for the rest of the language
>>>features.
>>>
>>>> On Jul 18, 2017, at 12:24 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> Pretty sure in AS for Flash, you can write (without "new"):
>>>>
>>>> var herbs:XML = XML(someXMLListWithOneElement);
>>>>
>>>> And it will "do the right thing".
>>>>
>>>> I guess we will have to create Language.XML or add a static toXML() on
>>>> XML
>>>> and have the compiler catch the top-level function call and redirect
>>>>it
>>>> to
>>>> that conversion function.
>>>>
>>>> Thoughts?
>>>> -Alex
>>>>
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.ad
>>>>ob
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.a
>>>>dob>
>>>> e.com
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe.com%
>>>>2F&data=02%7C01%7C%7C5382fcba9a4c46fe99a508d4cd9cc9d1%7Cfa7b1b5a7b34438
>>>>794aed2c178decee1%7C0%7C0%7C636359520659004208&sdata=puTvZn8XbISXRNbPzi
>>>>Kdy2QHDDh6OxiOhJwU4uz%2FtzM%3D&reserved=0>%2Fen_US%2FFlashPlatform%2Fre
>>>>ference%2Factionscript%2F3%2Fpackage&da
>>>>
>>>>ta=02%7C01%7C%7Ca738e996dd3d4b05159108d4cd5e8cc2%7Cfa7b1b5a7b34438794ae
>>>>d2
>>>>
>>>>c178decee1%7C0%7C0%7C636359253349448225&sdata=7YC%2B75edAjohFvpCU3Sd4d%
>>>>2B
>>>> RvWJYLlYGpyG5FHK5teQ%3D&reserved=0.
>>>> html#XML()
>>>>
>>>> On 7/17/17, 12:32 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> 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/sr
>>>>>c/
>>>>> ma
>>>>> in/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 <ha...@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 <ah...@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" <ha...@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
>>>>>>>>><ah...@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" <ha...@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
>>>>>>>>>>> <ah...@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" <ha...@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
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
Another reason to not add to Language is that it would make Language depend on XML.
I’ll try to write these functions today.
I don’t mind breaking up utility classes, but the Language class will need changes to the compiler. It looks like it’s more than just replacing org.apache.flex.utils.Language with org.apache.flex.utils (or something like that) because the compiler needs to know when to add goog.requires for each of the utility functions.
> On Jul 18, 2017, at 5:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> IMO, toXML() is more PAYG. We really shouldn't keep adding to Language.
>
> I'm going to figure out why your standalone functions like callLater,
> assert, etc, aren't handled correctly then we should seriously think about
> finding a volunteer to break up these utility classes into utility
> functions since that would be more PAYG.
>
> -Alex
>
> On 7/17/17, 2:55 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>> I believe you are right in Flash. Same for XMLList().
>>
>> I’d be happy to write the functions. Should we do a top level toXML() or
>> Language.XML() and Language.XMLList()?
>>
>> The latter seems to fit the pattern for the rest of the language features.
>>
>>> On Jul 18, 2017, at 12:24 AM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Pretty sure in AS for Flash, you can write (without "new"):
>>>
>>> var herbs:XML = XML(someXMLListWithOneElement);
>>>
>>> And it will "do the right thing".
>>>
>>> I guess we will have to create Language.XML or add a static toXML() on
>>> XML
>>> and have the compiler catch the top-level function call and redirect it
>>> to
>>> that conversion function.
>>>
>>> Thoughts?
>>> -Alex
>>>
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.adob <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.adob>
>>> e.com <http://e.com/>%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fpackage&da
>>> ta=02%7C01%7C%7Ca738e996dd3d4b05159108d4cd5e8cc2%7Cfa7b1b5a7b34438794aed2
>>> c178decee1%7C0%7C0%7C636359253349448225&sdata=7YC%2B75edAjohFvpCU3Sd4d%2B
>>> RvWJYLlYGpyG5FHK5teQ%3D&reserved=0.
>>> html#XML()
>>>
>>> On 7/17/17, 12:32 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> 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/
>>>> ma
>>>> in/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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>>> <ah...@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" <ha...@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
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, toXML() is more PAYG. We really shouldn't keep adding to Language.
I'm going to figure out why your standalone functions like callLater,
assert, etc, aren't handled correctly then we should seriously think about
finding a volunteer to break up these utility classes into utility
functions since that would be more PAYG.
-Alex
On 7/17/17, 2:55 PM, "Harbs" <ha...@gmail.com> wrote:
>I believe you are right in Flash. Same for XMLList().
>
>I’d be happy to write the functions. Should we do a top level toXML() or
>Language.XML() and Language.XMLList()?
>
>The latter seems to fit the pattern for the rest of the language features.
>
>> On Jul 18, 2017, at 12:24 AM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> Pretty sure in AS for Flash, you can write (without "new"):
>>
>> var herbs:XML = XML(someXMLListWithOneElement);
>>
>> And it will "do the right thing".
>>
>> I guess we will have to create Language.XML or add a static toXML() on
>>XML
>> and have the compiler catch the top-level function call and redirect it
>>to
>> that conversion function.
>>
>> Thoughts?
>> -Alex
>>
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.adob
>>e.com%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fpackage&da
>>ta=02%7C01%7C%7Ca738e996dd3d4b05159108d4cd5e8cc2%7Cfa7b1b5a7b34438794aed2
>>c178decee1%7C0%7C0%7C636359253349448225&sdata=7YC%2B75edAjohFvpCU3Sd4d%2B
>>RvWJYLlYGpyG5FHK5teQ%3D&reserved=0.
>> html#XML()
>>
>> On 7/17/17, 12:32 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> 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/
>>>ma
>>> in/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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>><ah...@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" <ha...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
I believe you are right in Flash. Same for XMLList().
I’d be happy to write the functions. Should we do a top level toXML() or Language.XML() and Language.XMLList()?
The latter seems to fit the pattern for the rest of the language features.
> On Jul 18, 2017, at 12:24 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Pretty sure in AS for Flash, you can write (without "new"):
>
> var herbs:XML = XML(someXMLListWithOneElement);
>
> And it will "do the right thing".
>
> I guess we will have to create Language.XML or add a static toXML() on XML
> and have the compiler catch the top-level function call and redirect it to
> that conversion function.
>
> Thoughts?
> -Alex
>
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.
> html#XML()
>
> On 7/17/17, 12:32 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> 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/ma
>> in/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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Pretty sure in AS for Flash, you can write (without "new"):
var herbs:XML = XML(someXMLListWithOneElement);
And it will "do the right thing".
I guess we will have to create Language.XML or add a static toXML() on XML
and have the compiler catch the top-level function call and redirect it to
that conversion function.
Thoughts?
-Alex
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.
html#XML()
On 7/17/17, 12:32 PM, "Harbs" <ha...@gmail.com> wrote:
>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/ma
>in/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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I thought we (you) already wrote one. If not, we won't we need one?
-Alex
On 7/17/17, 12:01 PM, "Harbs" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>
>>
>
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@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
>>
>
Re: [FlexJS XML] for each
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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
>
Re: [FlexJS XML] for each
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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