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.li...@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 <aha...@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" <harbs.li...@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 <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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
