Re: [FlexJS XML] for each

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

> On Jul 18, 2017, at 6:13 PM, Alex Harui 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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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" wrote: >Another reason to not add to Language is that it would make Language >depend on

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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]

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

I thought we (you) already wrote one. If not, we won't we need one? -Alex On 7/17/17, 12:01 PM, "Harbs" 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

Re: [FlexJS XML] for each

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 wrote: > > You can try

Re: [FlexJS XML] for each

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" wrote: >That is a fourth option. > >In terms of overhead, option

Re: [FlexJS XML] for each

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

Re: [FlexJS XML] for each

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

[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 =