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
> 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 is there a child textNode wi
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
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 erro
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 simpl
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 t
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 XML.
>
>I’ll try to write
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.Lan
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 sin
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 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
th
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]
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
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 level XML function. How does
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 #2 by changing ForEachEmit
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 #2 is probably cheapest
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 somet
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 jus
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.
19 matches
Mail list logo
