Re: [FlexJS XML] for each

[Justin Mclean]

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] technical debt

[Justin Mclean]

Hi,

So more than a week has gone by and I’ve received little feedback on [1]. Given 
that I’ll gone ahead and implement the rules as discussed in the document so 
people can see the changes.

The new results are up:
- First off the header rules is overly strict and expects a copyright line not 
just a header. ASF policy to not to have copyright lines so this is a false 
positive. I’ll disable the rule. We have other means to check headers. This 
will be fixed in the next run.
- The ASDocs rule is picking a lot of public methods and properties that don’t 
have ASDocs. I think we should keep this to remind us at some point it needs to 
be fixed / people can fix as they make edits.
- Is easier to see if issues that do need to be fixed. For instance I can see 
that there are a couple of event.clone issues that are likely bugs.

Thanks,
Justin

1.  https://cwiki.apache.org/confluence/display/FLEX/Sonar+Cube+Flex+Rules 

RE: [FlexJS] findPopupHost issue

[Yishay Weiss]

Even if the Application instance isn’t an IPopUpHost the method will just 
return null, so the effect is the same as just doing (appInstance as 
IPopUpHost). I suspect the method is being misused rather than there being a 
problem with the method.

From: Alex Harui
Sent: Tuesday, July 18, 2017 8:33 AM
To: dev@flex.apache.org
Subject: Re: [FlexJS] findPopupHost issue

FWIW, it may not be safe to assume that Application will always be an
IPopUpHost, hence the utility function.

Thanks,
-Alex

On 7/17/17, 9:59 PM, "piotrz"  wrote:

>Hi Yishay,
>
>That's a good point - Application is itself an IPopupHost. I've asked him
>what is the use case for his host popup search.
>
>Thanks,
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-findPopupHost-issue-tp63362p6
>3366.html=02%7C01%7C%7Cbfd19d2deba646c64df208d4cd9c9798%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636359519816386890=CyeQuoJ0gVVl2UHUB
>W%2B6hbyDNw%2FOSFuswfzeLTqUf3c%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS XML] for each

[Alex Harui]

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 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 
>>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" >> 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 
 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 

 e.com 
%2Fen_US%2FFlashPlatform%2Fre
ference%2Factionscript%2F3%2Fpackage
 
ta=02%7C01%7C%7Ca738e996dd3d4b05159108d4cd5e8cc2%7Cfa7b1b5a7b34438794ae
d2
 
c178decee1%7C0%7C0%7C636359253349448225=7YC%2B75edAjohFvpCU3Sd4d%
2B
 RvWJYLlYGpyG5FHK5teQ%3D=0.
 html#XML()
 
 On 7/17/17, 12:32 PM, "Harbs"  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  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 
>>> 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"  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
>
> wrote:
> 
> You can try #2 by changing ForEachEmitter.java.
> 

Re: [01/10] git commit: [flex-asjs] [refs/heads/refactor-strand] - Core changes to IStrand

[Harbs]

Not surprised. I still have quite a bit to do before I’d expect it to build.


> On Jul 18, 2017, at 7:20 AM, piotrz  wrote:
> 
> Hi Harbs,
> 
> I've created pipelines for your strand-work branch. Just run the build and
> it failed [1].
> 
> [1]
> https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20Pipeline/job/feature%252Fstrand-work/2/console
> 
> Thanks,
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/Re-01-10-git-commit-flex-asjs-refs-heads-refactor-strand-Core-changes-to-IStrand-tp63279p63363.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] findPopupHost issue

[Alex Harui]

FWIW, it may not be safe to assume that Application will always be an
IPopUpHost, hence the utility function.

Thanks,
-Alex

On 7/17/17, 9:59 PM, "piotrz"  wrote:

>Hi Yishay,
>
>That's a good point - Application is itself an IPopupHost. I've asked him
>what is the use case for his host popup search.
>
>Thanks, 
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-findPopupHost-issue-tp63362p6
>3366.html=02%7C01%7C%7Cbfd19d2deba646c64df208d4cd9c9798%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636359519816386890=CyeQuoJ0gVVl2UHUB
>W%2B6hbyDNw%2FOSFuswfzeLTqUf3c%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS XML] for each

[Harbs]

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  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"  > 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 
>>> 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
>>> ta=02%7C01%7C%7Ca738e996dd3d4b05159108d4cd5e8cc2%7Cfa7b1b5a7b34438794aed2
>>> c178decee1%7C0%7C0%7C636359253349448225=7YC%2B75edAjohFvpCU3Sd4d%2B
>>> RvWJYLlYGpyG5FHK5teQ%3D=0.
>>> html#XML()
>>> 
>>> On 7/17/17, 12:32 PM, "Harbs"  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  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 
>> 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"  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 
 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"  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 

RE: [FlexJS] findPopupHost issue

[piotrz]

Hi Yishay,

That's a good point - Application is itself an IPopupHost. I've asked him
what is the use case for his host popup search.

Thanks, 
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-findPopupHost-issue-tp63362p63366.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [FlexJS] findPopupHost issue

[Yishay Weiss]

I think there’s confusion over what a popup host is. A popup host is where you 
would add an IPopUp. UIUtils.findPopUpHost(myComp as IUIBase) finds the closest 
ancestor for myComp to which a popup can be added. These lines from 
ComboBoxView demonstrate the usage:

   var popupHost:IPopUpHost = 
UIUtils.findPopUpHost(_strand as IUIBase);
   popupHost.addElement(list);

Regarding Prashant’s issue, an application is usually in itself an IPopUpHost 
so there’s no need to use that function on an app.

From: piotrz
Sent: Tuesday, July 18, 2017 7:31 AM
To: dev@flex.apache.org
Subject: [FlexJS] findPopupHost issue

Hi Team,

Prashant on users list raised an issue with UIUtils.findPopUpHost(this as
IUIBase) [1]. I did quick look into that and I think we should have in
findPopUpHost(start:IPopupHost) instead findPopUpHost(start:IUIBase) or Am I
miss something ?

[1]
http://apache-flex-users.246.n4.nabble.com/FlexJS-findPopUpHost-Issue-td15474.html

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-findPopupHost-issue-tp63362.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

So I’ve looked into it and have rough version code up and so far:
- Requires support of styleName in AS which AFAICS is missing and/or not 
working. Without this 9 CSS classes are needed rather than 6 CSS classes.
- DataToolTipBead overrides determinePosition so the base function is still 
required returning null and rollOverHandler needs checking that return (i.e. 
more just in case code)
- More just in case code is need on JS and AS to check if there is a class 
sector in use and if not default to the “bottom right” one.
- CSS is not optimised by the optimiser, the code is.

While it may be more flexible it's is ending up fatter / has more just in case 
code that the current checked in version so I don’t think it a solution for 
this bead. It may be for a more heavy weight one.

Thanks,
Justin

Re: [01/10] git commit: [flex-asjs] [refs/heads/refactor-strand] - Core changes to IStrand

[piotrz]

Hi Harbs,

I've created pipelines for your strand-work branch. Just run the build and
it failed [1].

[1]
https://builds.apache.org/view/E-G/view/Flex/job/FlexJS%20Pipeline/job/feature%252Fstrand-work/2/console

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-01-10-git-commit-flex-asjs-refs-heads-refactor-strand-Core-changes-to-IStrand-tp63279p63363.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] findPopupHost issue

[piotrz]

Hi Team,

Prashant on users list raised an issue with UIUtils.findPopUpHost(this as
IUIBase) [1]. I did quick look into that and I think we should have in
findPopUpHost(start:IPopupHost) instead findPopUpHost(start:IUIBase) or Am I
miss something ?

[1]
http://apache-flex-users.246.n4.nabble.com/FlexJS-findPopUpHost-Issue-td15474.html

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-findPopupHost-issue-tp63362.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Falcon AsJS Mismatch?

[Alex Harui]

I'll see if I can fix it.

On 7/17/17, 3:05 PM, "Harbs"  wrote:

>I don’t remember.
>
>I don’t see where I commented out a test. It looks like I created an
>invalid test. Really odd, because I would have thought I’d notice that it
>wasn’t working. Also odd, because three backslashes seems correct.
>Shouldn’t that be \” rather than \\” ?
>
>Can you fix my mess or should I try tomorrow? (Shutting down for the
>night.)
>
>> On Jul 18, 2017, at 12:42 AM, Alex Harui 
>>wrote:
>> 
>> Harbs, the log indicates that the last person in that code was you and
>>you
>> commented out the test that would have caught this.  What was the reason
>> for that?
>> 
>> See log entry 0461e3917.
>> 
>> 
>> -Alex
>> 
>> On 7/17/17, 2:35 PM, "Alex Harui"  wrote:
>> 
>>> That's odd.  That isn't even RegEx, or am I missing something?  I
>>>didn't
>>> think I changed the non-RegEx code paths.
>>> 
>>> I'll take a look.
>>> 
>>> -Alex
>>> 
>>> On 7/17/17, 1:18 PM, "Harbs"  wrote:
>>> 
 I’m sorry to report:
 
 In XMLTest, the following:
 private var quotedXML : XML =;
 
 Outputs:
 this.quotedXML = new XML( "”);
 
 which quite obviously produces an error…
 
> On Jul 17, 2017, at 10:23 AM, Alex Harui 
> wrote:
> 
> I pushed a few more changes.  Hopefully nothing else broke.
> 
> -Alex
> 
> On 7/16/17, 8:52 AM, "Harbs"  > wrote:
> 
>> I wasn’t complaining. I was sympathizing.
>> 
>> If I knew how, I’d help.
>> 
>> Harbs
>> 
>>> On Jul 16, 2017, at 6:30 PM, Alex Harui 
>>> wrote:
>>> 
>>> Someone else is welcome to take over.  This stuff is not something
>>>I
>>> enjoy
>>> doing at all.
>>> 
>>> -Alex
>>> 
>>> On 7/16/17, 5:17 AM, "Harbs" >> >>
>>>wrote:
>>> 
 Is this with Alex’s latest changes?
 
 These backslash escapes seem really difficult to get right… :-(
 
> On Jul 16, 2017, at 2:41 PM, yishayw  > wrote:
> 
> Looks like falcon is incompatible with TabStopsPropety.as in TLF.
> When
> initializing that file I'm getting the following RTE:
> 
> Uncaught syntax error: Invalid regular expression: missing /
> 
> which originates in TabStopsProperty.as:191
> 
>   private static const _escapeBackslashRegex:RegExp = 
> //g;
> 
> 
> which transpiles to TabStopsProperty.js:143
> 
> 
> 
> 
> 
> 
>org.apache.flex.textLayout.property.TabStopsProperty._escapeBacksl
>as
> h
> Re
> ge
> x =
> /\/g;
> 
> 
> 
> 
> 
> --
> View this message in context:
> 
> 
> 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fap
>ac
> h
> e- 
> 
>pa
> c
> he->
> fl 
> 
> 
>pa
> c
> he 
> 
>pa
> c
> he>
> -fl>
> ex-development.247.n4.nabble.com
> 
>x-
> d
> 
>evelopment.247.n4.nabble.com%2F=02%7C01%7C%7Ce5a406810700
>40
> 2
> 
>b31cb08d4cd510f44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636
>35
> 9
> 
>195409825752=5lV1MGq8XIndXQTBJJsUl9gtjrWxbY89lcvwQpLiWdo%3D&
>re
> s
> erved=0>
> 
> 
>x-
> d
> ev 
> 
>x-
> d
> ev>
> elopment.247.n4.nabble.com
> 
>lo
> p
> 
>ment.247.n4.nabble.com%2F=02%7C01%7C%7Ce5a406810700402b31
>cb
> 0
> 
>8d4cd510f44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636359195
>40
> 9
> 
>825752=4BTTz0mtQKLypzDOZNGTKo1T134g9wIhYeh6Lmk24i4%3D
>ed
> =
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - Added support for JS upload progress events

[Justin Mclean]

Hi,

I can see these event name changes haven’t been reverted yet. Do you want me to 
do that for you?

I also note the code is using "”+requestStatus to convert a number to a string. 
Any reason for not using the toString or String(requestStatus) instead?

Thanks,
Justin

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

> All of those ifs are effectively "just-in-case" code.

With are likely to be optimised by the compiler AFAIK it doesn’t do that with 
CSS but I’ll look into it.

Thanks,
Justin

Re: [FlexJS XML] for each

[Alex Harui]

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"  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 
>>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
>>ta=02%7C01%7C%7Ca738e996dd3d4b05159108d4cd5e8cc2%7Cfa7b1b5a7b34438794aed2
>>c178decee1%7C0%7C0%7C636359253349448225=7YC%2B75edAjohFvpCU3Sd4d%2B
>>RvWJYLlYGpyG5FHK5teQ%3D=0.
>> html#XML()
>> 
>> On 7/17/17, 12:32 PM, "Harbs"  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  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 
> 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"  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 
>>> 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"  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
>
> 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:
> 

Re: [FlexJS] Falcon AsJS Mismatch?

[Harbs]

I don’t remember.

I don’t see where I commented out a test. It looks like I created an invalid 
test. Really odd, because I would have thought I’d notice that it wasn’t 
working. Also odd, because three backslashes seems correct. Shouldn’t that be 
\” rather than \\” ?

Can you fix my mess or should I try tomorrow? (Shutting down for the night.)

> On Jul 18, 2017, at 12:42 AM, Alex Harui  wrote:
> 
> Harbs, the log indicates that the last person in that code was you and you
> commented out the test that would have caught this.  What was the reason
> for that?
> 
> See log entry 0461e3917.
> 
> 
> -Alex
> 
> On 7/17/17, 2:35 PM, "Alex Harui"  wrote:
> 
>> That's odd.  That isn't even RegEx, or am I missing something?  I didn't
>> think I changed the non-RegEx code paths.
>> 
>> I'll take a look.
>> 
>> -Alex
>> 
>> On 7/17/17, 1:18 PM, "Harbs"  wrote:
>> 
>>> I’m sorry to report:
>>> 
>>> In XMLTest, the following:
>>> private var quotedXML : XML =;
>>> 
>>> Outputs:
>>> this.quotedXML = new XML( "”);
>>> 
>>> which quite obviously produces an error…
>>> 
 On Jul 17, 2017, at 10:23 AM, Alex Harui 
 wrote:
 
 I pushed a few more changes.  Hopefully nothing else broke.
 
 -Alex
 
 On 7/16/17, 8:52 AM, "Harbs" > wrote:
 
> I wasn’t complaining. I was sympathizing.
> 
> If I knew how, I’d help.
> 
> Harbs
> 
>> On Jul 16, 2017, at 6:30 PM, Alex Harui 
>> wrote:
>> 
>> Someone else is welcome to take over.  This stuff is not something I
>> enjoy
>> doing at all.
>> 
>> -Alex
>> 
>> On 7/16/17, 5:17 AM, "Harbs" > >> wrote:
>> 
>>> Is this with Alex’s latest changes?
>>> 
>>> These backslash escapes seem really difficult to get right… :-(
>>> 
 On Jul 16, 2017, at 2:41 PM, yishayw > wrote:
 
 Looks like falcon is incompatible with TabStopsPropety.as in TLF.
 When
 initializing that file I'm getting the following RTE:
 
 Uncaught syntax error: Invalid regular expression: missing /
 
 which originates in TabStopsProperty.as:191
 
private static const _escapeBackslashRegex:RegExp = 
 //g;
 
 
 which transpiles to TabStopsProperty.js:143
 
 
 
 
 
 org.apache.flex.textLayout.property.TabStopsProperty._escapeBackslas
 h
 Re
 ge
 x =
 /\/g;
 
 
 
 
 
 --
 View this message in context:
 
 
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapac
 h
 e- 
 
 fl 
 
 
 -fl>
 ex-development.247.n4.nabble.com
 
 
 
 elopment.247.n4.nabble.com
 %2F=02%7C01%7C%7Ca86baabe6d9844f6e02
 
 108d4cc62bac8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358171
 7
 93
 
 839919=LdNHLjstVY2Y0sUEQUG8QYoqlpj4G1n4pEalE4FaKwE%3D
 =
 0>
 %2FFlexJS-Falcon-AsJS-Mismatch-tp6329
 
 
 6.html=02%7C01%7C%7C7636647c1c22433fc7f508d4cc44ab08%7Cfa7b1b5a
 7
 b3
 44
 
 
 38794aed2c178decee1%7C0%7C0%7C636358042688036466=ZYSsWDWEs54Zs
 4
 sX
 IY
 

Re: [FlexJS XML] for each

[Harbs]

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

Re: [FlexJS] Falcon AsJS Mismatch?

[Alex Harui]

Harbs, the log indicates that the last person in that code was you and you
commented out the test that would have caught this.  What was the reason
for that?

See log entry 0461e3917.


-Alex

On 7/17/17, 2:35 PM, "Alex Harui"  wrote:

>That's odd.  That isn't even RegEx, or am I missing something?  I didn't
>think I changed the non-RegEx code paths.
>
>I'll take a look.
>
>-Alex
>
>On 7/17/17, 1:18 PM, "Harbs"  wrote:
>
>>I’m sorry to report:
>>
>>In XMLTest, the following:
>>private var quotedXML : XML =;
>>
>>Outputs:
>>this.quotedXML = new XML( "”);
>>
>>which quite obviously produces an error…
>>
>>> On Jul 17, 2017, at 10:23 AM, Alex Harui 
>>>wrote:
>>> 
>>> I pushed a few more changes.  Hopefully nothing else broke.
>>> 
>>> -Alex
>>> 
>>> On 7/16/17, 8:52 AM, "Harbs" >>> wrote:
>>> 
 I wasn’t complaining. I was sympathizing.
 
 If I knew how, I’d help.
 
 Harbs
 
> On Jul 16, 2017, at 6:30 PM, Alex Harui 
> wrote:
> 
> Someone else is welcome to take over.  This stuff is not something I
> enjoy
> doing at all.
> 
> -Alex
> 
> On 7/16/17, 5:17 AM, "Harbs"  >> wrote:
> 
>> Is this with Alex’s latest changes?
>> 
>> These backslash escapes seem really difficult to get right… :-(
>> 
>>> On Jul 16, 2017, at 2:41 PM, yishayw >>> wrote:
>>> 
>>> Looks like falcon is incompatible with TabStopsPropety.as in TLF.
>>>When
>>> initializing that file I'm getting the following RTE:
>>> 
>>> Uncaught syntax error: Invalid regular expression: missing /
>>> 
>>> which originates in TabStopsProperty.as:191
>>> 
>>> private static const _escapeBackslashRegex:RegExp = 
>>> //g;
>>> 
>>> 
>>> which transpiles to TabStopsProperty.js:143
>>> 
>>> 
>>> 
>>> 
>>> 
>>>org.apache.flex.textLayout.property.TabStopsProperty._escapeBackslas
>>>h
>>>Re
>>> ge
>>> x =
>>> /\/g;
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> 
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapac
>>>h
>>>e- 
>>>>>c
>>>he->
>>> fl 
>>> 
>>>>>c
>>>he 
>>>>>c
>>>he>
>>> -fl>
>>> ex-development.247.n4.nabble.com
>>>>>d
>>>evelopment.247.n4.nabble.com%2F=02%7C01%7C%7Ce5a40681070040
>>>2
>>>b31cb08d4cd510f44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635
>>>9
>>>195409825752=5lV1MGq8XIndXQTBJJsUl9gtjrWxbY89lcvwQpLiWdo%3D
>>>s
>>>erved=0>
>>> 
>>>>>d
>>>ev 
>>>>>d
>>>ev>
>>> elopment.247.n4.nabble.com
>>>>>p
>>>ment.247.n4.nabble.com%2F=02%7C01%7C%7Ce5a406810700402b31cb
>>>0
>>>8d4cd510f44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635919540
>>>9
>>>825752=4BTTz0mtQKLypzDOZNGTKo1T134g9wIhYeh6Lmk24i4%3D
>>>=
>>>0>%2F=02%7C01%7C%7Ca86baabe6d9844f6e02
>>> 
>>>108d4cc62bac8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358171
>>>7
>>>93
>>> 
>>>839919=LdNHLjstVY2Y0sUEQUG8QYoqlpj4G1n4pEalE4FaKwE%3D
>>>=
>>>0>
>>> %2FFlexJS-Falcon-AsJS-Mismatch-tp6329
>>> 
>>> 
>>>6.html=02%7C01%7C%7C7636647c1c22433fc7f508d4cc44ab08%7Cfa7b1b5a
>>>7
>>>b3
>>> 44
>>> 
>>> 
>>>38794aed2c178decee1%7C0%7C0%7C636358042688036466=ZYSsWDWEs54Zs
>>>4
>>>sX
>>> IY
>>> k2SrHt%2FnurGBhIb8VYAH6zQtM%3D=0
>>> Sent from the Apache Flex Development mailing list archive at
>>> Nabble.com 
>>>>>b
>>>le.com%2F=02%7C01%7C%7Ce5a406810700402b31cb08d4cd510f44%7Cfa7b1
>>>b
>>>5a7b34438794aed2c178decee1%7C0%7C0%7C636359195409825752=TEb4Au
>>>u
>>>OOO1qTSdWrd5EOZKwfp954EYyVV4T8%2BzA9Lw%3D=0>
>>> 
>>>>>b
>>>le 
>>>>>b
>>>le>
>>> 

Re: [FlexJS] Falcon AsJS Mismatch?

[Alex Harui]

That's odd.  That isn't even RegEx, or am I missing something?  I didn't
think I changed the non-RegEx code paths.

I'll take a look.

-Alex

On 7/17/17, 1:18 PM, "Harbs"  wrote:

>I’m sorry to report:
>
>In XMLTest, the following:
>private var quotedXML : XML =;
>
>Outputs:
>this.quotedXML = new XML( "”);
>
>which quite obviously produces an error…
>
>> On Jul 17, 2017, at 10:23 AM, Alex Harui 
>>wrote:
>> 
>> I pushed a few more changes.  Hopefully nothing else broke.
>> 
>> -Alex
>> 
>> On 7/16/17, 8:52 AM, "Harbs" >> wrote:
>> 
>>> I wasn’t complaining. I was sympathizing.
>>> 
>>> If I knew how, I’d help.
>>> 
>>> Harbs
>>> 
 On Jul 16, 2017, at 6:30 PM, Alex Harui 
 wrote:
 
 Someone else is welcome to take over.  This stuff is not something I
 enjoy
 doing at all.
 
 -Alex
 
 On 7/16/17, 5:17 AM, "Harbs" >> wrote:
 
> Is this with Alex’s latest changes?
> 
> These backslash escapes seem really difficult to get right… :-(
> 
>> On Jul 16, 2017, at 2:41 PM, yishayw >> wrote:
>> 
>> Looks like falcon is incompatible with TabStopsPropety.as in TLF.
>>When
>> initializing that file I'm getting the following RTE:
>> 
>> Uncaught syntax error: Invalid regular expression: missing /
>> 
>> which originates in TabStopsProperty.as:191
>> 
>>  private static const _escapeBackslashRegex:RegExp = //g;
>> 
>> 
>> which transpiles to TabStopsProperty.js:143
>> 
>> 
>> 
>> 
>> 
>>org.apache.flex.textLayout.property.TabStopsProperty._escapeBackslash
>>Re
>> ge
>> x =
>> /\/g;
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> 
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapach
>>e- 
>>>he->
>> fl 
>> 
>>>he 
>>>he>
>> -fl>
>> ex-development.247.n4.nabble.com
>>>evelopment.247.n4.nabble.com%2F=02%7C01%7C%7Ce5a406810700402
>>b31cb08d4cd510f44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636359
>>195409825752=5lV1MGq8XIndXQTBJJsUl9gtjrWxbY89lcvwQpLiWdo%3D
>>erved=0>
>> 
>>>ev 
>>>ev>
>> elopment.247.n4.nabble.com
>>>ment.247.n4.nabble.com%2F=02%7C01%7C%7Ce5a406810700402b31cb0
>>8d4cd510f44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636359195409
>>825752=4BTTz0mtQKLypzDOZNGTKo1T134g9wIhYeh6Lmk24i4%3D=
>>0>%2F=02%7C01%7C%7Ca86baabe6d9844f6e02
>> 
>>108d4cc62bac8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363581717
>>93
>> 
>>839919=LdNHLjstVY2Y0sUEQUG8QYoqlpj4G1n4pEalE4FaKwE%3D=
>>0>
>> %2FFlexJS-Falcon-AsJS-Mismatch-tp6329
>> 
>> 
>>6.html=02%7C01%7C%7C7636647c1c22433fc7f508d4cc44ab08%7Cfa7b1b5a7
>>b3
>> 44
>> 
>> 
>>38794aed2c178decee1%7C0%7C0%7C636358042688036466=ZYSsWDWEs54Zs4
>>sX
>> IY
>> k2SrHt%2FnurGBhIb8VYAH6zQtM%3D=0
>> Sent from the Apache Flex Development mailing list archive at
>> Nabble.com 
>>>le.com%2F=02%7C01%7C%7Ce5a406810700402b31cb08d4cd510f44%7Cfa7b1b
>>5a7b34438794aed2c178decee1%7C0%7C0%7C636359195409825752=TEb4Auu
>>OOO1qTSdWrd5EOZKwfp954EYyVV4T8%2BzA9Lw%3D=0>
>> 
>>>le 
>>>le>
>> 
>>.com%2F=02%7C01%7C%7Ca86baabe6d9844f6e02108d4cc62bac8%7Cfa7b1b5a
>>7b
>> 
>>34438794aed2c178decee1%7C0%7C0%7C636358171793839919=UVgi9RhUfOU
>>%2
>> B1jBQOH%2BfnSIqJIdqdRR4q84X4x5kZYQ%3D=0>.
>

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Alex Harui]

"var self = this;” is added to every method that has inner/local
functions.  Use of "this" in local functions is changed to use "self" in
order to get AS scoping in JS.  I think we currently generate a self=this
even if the local functions don't need it.  Someday the compiler will be
smarter about that.


If the compiler is now generating self=this where there are no local
functions, that would be a bug.

-Alex

On 7/17/17, 2:23 PM, "Harbs"  wrote:

>The places that I checked look good.
>
>Side question: Despite the fact that “this” is no longer used in the
>callLater function, I noticed that the compiler is inserting "var self =
>this;” at the start of the function.
>
>I don’t think it causes any harm, but it does cause a Google compiler
>warning and I’m curious as to why it’s being output.
>
>> On Jul 17, 2017, at 10:36 PM, Harbs  wrote:
>> 
>> I’m not going to claim I understand what you just wrote. ;-)
>> 
>> I’ll see if I can understand the output…
>> 
>> Thanks.
>> 
>>> On Jul 17, 2017, at 10:33 PM, Alex Harui 
>>>wrote:
>>> 
>>> Thinking about it more, I think a parameter of type Function never
>>>needs
>>> to be wrapped.  It would get wrapped on any assignment in the function
>>> body.  I just pushed changes to reflect that.
>>> 
>>> -Alex
>>> 
>>> On 7/16/17, 11:41 PM, "Alex Harui"  wrote:
>>> 
 Seems reasonable to add a check to see if the function body is for a
 static method.
 
 -Alex
 
 On 7/16/17, 11:25 PM, "Harbs"  wrote:
 
> A directive could be a solution.
> 
> But I think this is an issue with any static method. If a closure is
>used
> inside a static method, or a function declared inside a static
>method, it
> should not use Language.closure.
> 
> FWIW, the Google compile complains about “this” being used in a
>static
> method as well:
> 
>  [mxmlc] Jul 16, 2017 7:26:08 PM
> com.google.javascript.jscomp.LoggerErrorManager println
>  [mxmlc] WARNING:
> 
>/Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingE
>xam
> p
> le/bin/js-debug/org/apache/flex/utils/callLater.js:35: WARNING -
> dangerous use of this in static method
>org.apache.flex.utils.callLater
>  [mxmlc]   
> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
> 'makeCalls'), 0);
> 
> Package level functions should be treated as static methods.
> 
> It might not be a bad idea to add a directive to allow developers to
> avoid Language.closure calls at will, but I think the “correct”
>general
> solution is to never output Language.closure in static and package
>level
> functions.
> 
>> On Jul 17, 2017, at 9:16 AM, Alex Harui 
>> wrote:
>> 
>> I don't see any current way to suppress the Language.closure.
>>Without
>> flow-analysis, I'm not sure the compiler can tell.  It could guess
>>that
>> the identifier is a parameter, but the parameter variable could be
>> assigned within the function body.
>> 
>> We could add a new directive like @flexjsisclosure or something like
>> that.
>> 
>> Thoughts?
>> -Alex
>> 
>> On 7/16/17, 10:05 AM, "Harbs"  wrote:
>> 
>>> I figured out the problem.
>>> 
>>> org.apache.flex.utils.callLater has the following code:
>>> setTimeout(makeCalls, 0);
>>> 
>>> That compiles to:
>>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>>> 'makeCalls'), 0);
>>> 
>>> When Language.closure is called, it messes up the scope of the
>>>calls
>>> variable and subsequent calls to makeCalls step on each other. I
>>> believe
>>> this is because makeCalls is bound to the package object of the
>>> callLater
>>> function.
>>> 
>>> Is there any way to prevent rewriting of function calls to
>>> Language.closure?
>>> 
>>> If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
>>> "setTimeout(makeCalls, 0);", it works like I’d expect it to.
>>> 
>>> Thanks,
>>> Harbs
>>> 
 On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
 
 Interesting to note:
 
 Adding a number of callLater() calls resulted in only the first
one
 being called in JS. I did not try as a SWF.
>>> 
>> 
> 
 
>>> 
>> 
>

Re: [FlexJS XML] for each

[Alex Harui]

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"  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  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 
>>>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"  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 
> 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"  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 
>>> 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"  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 

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Harbs]

The places that I checked look good.

Side question: Despite the fact that “this” is no longer used in the callLater 
function, I noticed that the compiler is inserting "var self = this;” at the 
start of the function.

I don’t think it causes any harm, but it does cause a Google compiler warning 
and I’m curious as to why it’s being output.

> On Jul 17, 2017, at 10:36 PM, Harbs  wrote:
> 
> I’m not going to claim I understand what you just wrote. ;-)
> 
> I’ll see if I can understand the output…
> 
> Thanks.
> 
>> On Jul 17, 2017, at 10:33 PM, Alex Harui  wrote:
>> 
>> Thinking about it more, I think a parameter of type Function never needs
>> to be wrapped.  It would get wrapped on any assignment in the function
>> body.  I just pushed changes to reflect that.
>> 
>> -Alex
>> 
>> On 7/16/17, 11:41 PM, "Alex Harui"  wrote:
>> 
>>> Seems reasonable to add a check to see if the function body is for a
>>> static method.
>>> 
>>> -Alex
>>> 
>>> On 7/16/17, 11:25 PM, "Harbs"  wrote:
>>> 
 A directive could be a solution.
 
 But I think this is an issue with any static method. If a closure is used
 inside a static method, or a function declared inside a static method, it
 should not use Language.closure.
 
 FWIW, the Google compile complains about “this” being used in a static
 method as well:
 
  [mxmlc] Jul 16, 2017 7:26:08 PM
 com.google.javascript.jscomp.LoggerErrorManager println
  [mxmlc] WARNING:
 /Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingExam
 p
 le/bin/js-debug/org/apache/flex/utils/callLater.js:35: WARNING -
 dangerous use of this in static method org.apache.flex.utils.callLater
  [mxmlc]   
 setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
 'makeCalls'), 0);
 
 Package level functions should be treated as static methods.
 
 It might not be a bad idea to add a directive to allow developers to
 avoid Language.closure calls at will, but I think the “correct” general
 solution is to never output Language.closure in static and package level
 functions.
 
> On Jul 17, 2017, at 9:16 AM, Alex Harui 
> wrote:
> 
> I don't see any current way to suppress the Language.closure.  Without
> flow-analysis, I'm not sure the compiler can tell.  It could guess that
> the identifier is a parameter, but the parameter variable could be
> assigned within the function body.
> 
> We could add a new directive like @flexjsisclosure or something like
> that.
> 
> Thoughts?
> -Alex
> 
> On 7/16/17, 10:05 AM, "Harbs"  wrote:
> 
>> I figured out the problem.
>> 
>> org.apache.flex.utils.callLater has the following code:
>> setTimeout(makeCalls, 0);
>> 
>> That compiles to:
>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>> 'makeCalls'), 0);
>> 
>> When Language.closure is called, it messes up the scope of the calls
>> variable and subsequent calls to makeCalls step on each other. I
>> believe
>> this is because makeCalls is bound to the package object of the
>> callLater
>> function.
>> 
>> Is there any way to prevent rewriting of function calls to
>> Language.closure?
>> 
>> If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
>> "setTimeout(makeCalls, 0);", it works like I’d expect it to.
>> 
>> Thanks,
>> Harbs
>> 
>>> On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
>>> 
>>> Interesting to note:
>>> 
>>> Adding a number of callLater() calls resulted in only the first one
>>> being called in JS. I did not try as a SWF.
>> 
> 
 
>>> 
>> 
> 

Re: [FlexJS] Falcon AsJS Mismatch?

[Harbs]

I’m sorry to report:

In XMLTest, the following:
private var quotedXML : XML =;

Outputs:
this.quotedXML = new XML( "”);

which quite obviously produces an error…

> On Jul 17, 2017, at 10:23 AM, Alex Harui  wrote:
> 
> I pushed a few more changes.  Hopefully nothing else broke.
> 
> -Alex
> 
> On 7/16/17, 8:52 AM, "Harbs"  > wrote:
> 
>> I wasn’t complaining. I was sympathizing.
>> 
>> If I knew how, I’d help.
>> 
>> Harbs
>> 
>>> On Jul 16, 2017, at 6:30 PM, Alex Harui 
>>> wrote:
>>> 
>>> Someone else is welcome to take over.  This stuff is not something I
>>> enjoy
>>> doing at all.
>>> 
>>> -Alex
>>> 
>>> On 7/16/17, 5:17 AM, "Harbs" >> >> wrote:
>>> 
 Is this with Alex’s latest changes?
 
 These backslash escapes seem really difficult to get right… :-(
 
> On Jul 16, 2017, at 2:41 PM, yishayw  > wrote:
> 
> Looks like falcon is incompatible with TabStopsPropety.as in TLF. When
> initializing that file I'm getting the following RTE:
> 
> Uncaught syntax error: Invalid regular expression: missing /
> 
> which originates in TabStopsProperty.as:191
> 
>   private static const _escapeBackslashRegex:RegExp = //g;
> 
> 
> which transpiles to TabStopsProperty.js:143
> 
> 
> 
> 
> org.apache.flex.textLayout.property.TabStopsProperty._escapeBackslashRe
> ge
> x =
> /\/g;
> 
> 
> 
> 
> 
> --
> View this message in context:
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache- 
> 
> fl 
>  
> -fl>
> ex-development.247.n4.nabble.com 
> 
>  
> elopment.247.n4.nabble.com 
> %2F=02%7C01%7C%7Ca86baabe6d9844f6e02
> 108d4cc62bac8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358171793
> 839919=LdNHLjstVY2Y0sUEQUG8QYoqlpj4G1n4pEalE4FaKwE%3D=0>
> %2FFlexJS-Falcon-AsJS-Mismatch-tp6329
> 
> 6.html=02%7C01%7C%7C7636647c1c22433fc7f508d4cc44ab08%7Cfa7b1b5a7b3
> 44
> 
> 38794aed2c178decee1%7C0%7C0%7C636358042688036466=ZYSsWDWEs54Zs4sX
> IY
> k2SrHt%2FnurGBhIb8VYAH6zQtM%3D=0
> Sent from the Apache Flex Development mailing list archive at
> Nabble.com  
>  
> .com%2F=02%7C01%7C%7Ca86baabe6d9844f6e02108d4cc62bac8%7Cfa7b1b5a7b
> 34438794aed2c178decee1%7C0%7C0%7C636358171793839919=UVgi9RhUfOU%2
> B1jBQOH%2BfnSIqJIdqdRR4q84X4x5kZYQ%3D=0>.

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Harbs]

I’m not going to claim I understand what you just wrote. ;-)

I’ll see if I can understand the output…

Thanks.

> On Jul 17, 2017, at 10:33 PM, Alex Harui  wrote:
> 
> Thinking about it more, I think a parameter of type Function never needs
> to be wrapped.  It would get wrapped on any assignment in the function
> body.  I just pushed changes to reflect that.
> 
> -Alex
> 
> On 7/16/17, 11:41 PM, "Alex Harui"  wrote:
> 
>> Seems reasonable to add a check to see if the function body is for a
>> static method.
>> 
>> -Alex
>> 
>> On 7/16/17, 11:25 PM, "Harbs"  wrote:
>> 
>>> A directive could be a solution.
>>> 
>>> But I think this is an issue with any static method. If a closure is used
>>> inside a static method, or a function declared inside a static method, it
>>> should not use Language.closure.
>>> 
>>> FWIW, the Google compile complains about “this” being used in a static
>>> method as well:
>>> 
>>>   [mxmlc] Jul 16, 2017 7:26:08 PM
>>> com.google.javascript.jscomp.LoggerErrorManager println
>>>   [mxmlc] WARNING:
>>> /Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingExam
>>> p
>>> le/bin/js-debug/org/apache/flex/utils/callLater.js:35: WARNING -
>>> dangerous use of this in static method org.apache.flex.utils.callLater
>>>   [mxmlc]   
>>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>>> 'makeCalls'), 0);
>>> 
>>> Package level functions should be treated as static methods.
>>> 
>>> It might not be a bad idea to add a directive to allow developers to
>>> avoid Language.closure calls at will, but I think the “correct” general
>>> solution is to never output Language.closure in static and package level
>>> functions.
>>> 
 On Jul 17, 2017, at 9:16 AM, Alex Harui 
 wrote:
 
 I don't see any current way to suppress the Language.closure.  Without
 flow-analysis, I'm not sure the compiler can tell.  It could guess that
 the identifier is a parameter, but the parameter variable could be
 assigned within the function body.
 
 We could add a new directive like @flexjsisclosure or something like
 that.
 
 Thoughts?
 -Alex
 
 On 7/16/17, 10:05 AM, "Harbs"  wrote:
 
> I figured out the problem.
> 
> org.apache.flex.utils.callLater has the following code:
> setTimeout(makeCalls, 0);
> 
> That compiles to:
> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
> 'makeCalls'), 0);
> 
> When Language.closure is called, it messes up the scope of the calls
> variable and subsequent calls to makeCalls step on each other. I
> believe
> this is because makeCalls is bound to the package object of the
> callLater
> function.
> 
> Is there any way to prevent rewriting of function calls to
> Language.closure?
> 
> If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
> "setTimeout(makeCalls, 0);", it works like I’d expect it to.
> 
> Thanks,
> Harbs
> 
>> On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
>> 
>> Interesting to note:
>> 
>> Adding a number of callLater() calls resulted in only the first one
>> being called in JS. I did not try as a SWF.
> 
 
>>> 
>> 
> 

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Alex Harui]

Thinking about it more, I think a parameter of type Function never needs
to be wrapped.  It would get wrapped on any assignment in the function
body.  I just pushed changes to reflect that.

-Alex

On 7/16/17, 11:41 PM, "Alex Harui"  wrote:

>Seems reasonable to add a check to see if the function body is for a
>static method.
>
>-Alex
>
>On 7/16/17, 11:25 PM, "Harbs"  wrote:
>
>>A directive could be a solution.
>>
>>But I think this is an issue with any static method. If a closure is used
>>inside a static method, or a function declared inside a static method, it
>>should not use Language.closure.
>>
>>FWIW, the Google compile complains about “this” being used in a static
>>method as well:
>>
>>[mxmlc] Jul 16, 2017 7:26:08 PM
>>com.google.javascript.jscomp.LoggerErrorManager println
>>[mxmlc] WARNING:
>>/Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingExam
>>p
>>le/bin/js-debug/org/apache/flex/utils/callLater.js:35: WARNING -
>>dangerous use of this in static method org.apache.flex.utils.callLater
>>[mxmlc]   
>>setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>>'makeCalls'), 0);
>>
>>Package level functions should be treated as static methods.
>>
>>It might not be a bad idea to add a directive to allow developers to
>>avoid Language.closure calls at will, but I think the “correct” general
>>solution is to never output Language.closure in static and package level
>>functions.
>>
>>> On Jul 17, 2017, at 9:16 AM, Alex Harui 
>>>wrote:
>>> 
>>> I don't see any current way to suppress the Language.closure.  Without
>>> flow-analysis, I'm not sure the compiler can tell.  It could guess that
>>> the identifier is a parameter, but the parameter variable could be
>>> assigned within the function body.
>>> 
>>> We could add a new directive like @flexjsisclosure or something like
>>>that.
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>>> On 7/16/17, 10:05 AM, "Harbs"  wrote:
>>> 
 I figured out the problem.
 
 org.apache.flex.utils.callLater has the following code:
 setTimeout(makeCalls, 0);
 
 That compiles to:
 setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
 'makeCalls'), 0);
 
 When Language.closure is called, it messes up the scope of the calls
 variable and subsequent calls to makeCalls step on each other. I
believe
 this is because makeCalls is bound to the package object of the
callLater
 function.
 
 Is there any way to prevent rewriting of function calls to
 Language.closure?
 
 If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
 "setTimeout(makeCalls, 0);", it works like I’d expect it to.
 
 Thanks,
 Harbs
 
> On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
> 
> Interesting to note:
> 
> Adding a number of callLater() calls resulted in only the first one
> being called in JS. I did not try as a SWF.
 
>>> 
>>
>

Re: [FlexJS XML] for each

[Harbs]

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  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  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"  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 
 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"  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 
>> 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"  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()).
>>> 

Re: [FlexJS XML] for each

[Harbs]

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  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"  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 
>>> 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"  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 
> 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"  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

[Alex Harui]

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
>that work in Javascript?
>
>> On Jul 17, 2017, at 7:47 PM, Alex Harui 
>>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"  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 
 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"  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: [Falcon] operand stack underflow?

[Harbs]

Yes. I can compile now.

Thanks.

> On Jul 17, 2017, at 5:46 PM, Alex Harui  wrote:
> 
> I just pushed a fix for Yishay's problem.  Hopefully it fixes the stack
> underflow as well.
> 
> -Alex
> 
> On 7/17/17, 6:38 AM, "Yishay Weiss"  wrote:
> 
>> This [1] is what I get when building DataBindingExample. Says build is
>> successful but the following message suggests it is not:
>> 
>>   [mxmlc] Exception in thread "main" java.lang.AssertionError:
>> Unsupported property value: 1px solid #808080scanning for overrides:
>> IUIBase
>> 
>> [1] 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>> che.org%2FSTWV=02%7C01%7C%7Cf1bb25daf78840b0f68e08d4cd191b07%7Cfa7b1b
>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636358955087940048=SMj%2BQLhaog
>> 6J7PtqxlFPFzv7AhOSN6OMMkyOQS5poGs%3D=0
>> 
>> From: Yishay Weiss
>> Sent: Monday, July 17, 2017 4:24 PM
>> To: dev@flex.apache.org
>> Subject: RE: [Falcon] operand stack underflow?
>> 
>> I’m actually able to build after running the following batch file:
>> 
>> cd \dev\flexjs\flex-falcon
>> git pull
>> call ant wipe-all
>> cd \dev\flexjs\flex-typedefs
>> call ant wipe
>> git pull
>> cd \dev\flexjs\flex-asjs
>> call ant super-clean
>> git pull
>> ant clean all
>> 
>> 
>> I am however getting a runtime error because of the following line in
>> PortedPrintUI.js:
>> 
>> function() {this["border"] = ;
>> 
>> Which probably comes from basic -> defaults.css:
>> 
>> Button
>> {
>>  background-color: #f8f8f8;
>>  border: 1px solid #808080;
>>  border-radius: 2px;
>>  padding: 4px;
>>  margin: 0px;
>> }
>> 
>> I’ll try to create a simple test case.
>> 
>> From: Harbs
>> Sent: Monday, July 17, 2017 3:09 PM
>> To: dev
>> Subject: [Falcon] operand stack underflow?
>> 
>> I just updated flex-falcon and flex-asjs. After rebuilding everything,
>> I’m getting the following error when compiling my app:
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>> che.org%2F3wBr=02%7C01%7C%7Cf1bb25daf78840b0f68e08d4cd191b07%7Cfa7b1b
>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636358955087940048=RVopvSQrI66F
>> fl%2B5ydLUBGpIgnrc9LgRw8duGuUdAyY%3D=0
>> > ache.org%2F3wBr=02%7C01%7C%7Cf1bb25daf78840b0f68e08d4cd191b07%7Cfa7b1
>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636358955087940048=RVopvSQrI66
>> Ffl%2B5ydLUBGpIgnrc9LgRw8duGuUdAyY%3D=0>
>> 
>> This is a new one for me…
>> 
>> Suggestions?
>> 
>> Harbs
>> 
> 

Re: [FlexJS XML] for each

[Harbs]

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 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 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 
>>> 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"  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

[Alex Harui]

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 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 
>>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"  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

[Harbs]

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  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"  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

[Alex Harui]

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"  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: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Alex Harui]

All of those ifs are effectively "just-in-case" code.  The reason I asked
about using CSS is that it feels like you are creating a whole new layout
mechanism that CSS probably already has.  So if all of this code could be
replaced with, for example, a few lines code that adds a CSS class on the
tooltip and the CSS in that class selector is what drives the positioning,
I think that would be the smallest, most flexible way of allowing folks to
tweak the tooltip position and it would use a standard mechanism as well.

My 2 cents,
-Alex

On 7/16/17, 11:45 PM, "Justin Mclean"  wrote:

>Hi,
>
>> "Slightly fatter" might be acceptable.  Your changes looked like a lot
>>of
>> code.  
>
>Im not sure you are looking at the same changes I am.
>
> All that was added was:
>-  the TOP, BOTTOM, LEFT, RIGHT constants
>- an if statement with a number of else ifs to work out the positioning
>- changing this line:
>pt = new Point(comp.width, comp.height);
>to this:
>pt = new Point(comp.width/xFactor, comp.height/yFactor);
>
>That seems reasonably slim to me. What is your definition of “slightly
>fatter”?
>
>Thanks,
>Justin
>

Re: FlexJS MXML ids and classNames - FLEX-35310

[piotrz]

Hi Alex,

Ok for me personally that's not the problem. I will create that Bead as an
addition which helps with that bug.

Adding "localId" without touching "id" it can also satisfy my needs and
application which was touched by that problem.

I would be happy if other opinion appear on that issue.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63338.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [Falcon] operand stack underflow?

[Alex Harui]

I just pushed a fix for Yishay's problem.  Hopefully it fixes the stack
underflow as well.

-Alex

On 7/17/17, 6:38 AM, "Yishay Weiss"  wrote:

>This [1] is what I get when building DataBindingExample. Says build is
>successful but the following message suggests it is not:
>
>[mxmlc] Exception in thread "main" java.lang.AssertionError:
>Unsupported property value: 1px solid #808080scanning for overrides:
>IUIBase
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FSTWV=02%7C01%7C%7Cf1bb25daf78840b0f68e08d4cd191b07%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636358955087940048=SMj%2BQLhaog
>6J7PtqxlFPFzv7AhOSN6OMMkyOQS5poGs%3D=0
>
>From: Yishay Weiss
>Sent: Monday, July 17, 2017 4:24 PM
>To: dev@flex.apache.org
>Subject: RE: [Falcon] operand stack underflow?
>
>I’m actually able to build after running the following batch file:
>
>cd \dev\flexjs\flex-falcon
>git pull
>call ant wipe-all
>cd \dev\flexjs\flex-typedefs
>call ant wipe
>git pull
>cd \dev\flexjs\flex-asjs
>call ant super-clean
>git pull
>ant clean all
>
>
>I am however getting a runtime error because of the following line in
>PortedPrintUI.js:
>
>function() {this["border"] = ;
>
>Which probably comes from basic -> defaults.css:
>
>Button
>{
>   background-color: #f8f8f8;
>   border: 1px solid #808080;
>   border-radius: 2px;
>   padding: 4px;
>   margin: 0px;
>}
>
>I’ll try to create a simple test case.
>
>From: Harbs
>Sent: Monday, July 17, 2017 3:09 PM
>To: dev
>Subject: [Falcon] operand stack underflow?
>
>I just updated flex-falcon and flex-asjs. After rebuilding everything,
>I’m getting the following error when compiling my app:
>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2F3wBr=02%7C01%7C%7Cf1bb25daf78840b0f68e08d4cd191b07%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636358955087940048=RVopvSQrI66F
>fl%2B5ydLUBGpIgnrc9LgRw8duGuUdAyY%3D=0
>ache.org%2F3wBr=02%7C01%7C%7Cf1bb25daf78840b0f68e08d4cd191b07%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636358955087940048=RVopvSQrI66
>Ffl%2B5ydLUBGpIgnrc9LgRw8duGuUdAyY%3D=0>
>
>This is a new one for me…
>
>Suggestions?
>
>Harbs
>

Re: FlexJS MXML ids and classNames - FLEX-35310

[Alex Harui]

Hi Piotr,

I still don't think the compiler can tell if you will be using an id more
than once.  At least not with a lot of flow analysis and even then I think
we'd miss cases.

You should be able to use the same id more than once.  You might be
removing the first view and replacing it with a different view and both
might have the same id.

IMO, the only warning must be done at runtime.  Feel free to create a
DuplicateIDCheckingBead that does that work.  I think it would replace the
UIBase id setter with a version that calls getElementById on the proposed
id.

My 2 cents,
-Alex

On 7/17/17, 3:20 AM, "piotrz"  wrote:

>Hi Alex,
>
>That's a valid point and I think I'm willing to change my vote to have
>localId. Let me understand fully this. If we introduce "localId" -
>
>- We will be able to have same id in different view - Introducing that new
>field is less time consuming than doing solution which I vote for ?
>- Compiler will shot us some warning if we have duplicate "id" ?
>
>Thanks,
>Piotr
>
>
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-tp543
>61p63328.html=02%7C01%7C%7C8772b947ed204967a34408d4cd002f3c%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636358848070298436=18lcB0kmjhL1q
>64dKeWha7%2B96F%2F%2BtECazuFZ2X2F5AM%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FYI: React appears to be a no-no

[Alex Harui]

IMO, it would not preclude a reactjs component set.  You can have Cat-X
dependencies as long as they are optional.  One of the measures of whether
a dependency is optional is whether or not a majority of users use that
dependency.  Just like the CreateJS component set, we can put together a
first cut and if it becomes wildly popular then that community would
probably take responsibility for the component set and its distribution to
customers.

-Alex

On 7/17/17, 3:16 AM, "Harbs"  wrote:

>As Dave said, let’s see how this plays out at Facebook, but it’s
>currently not looking too great.[1]
>
>My understanding is that it would preclude a reactjs component set, but I
>could be wrong.
>
>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
>.com%2Ffacebook%2Freact%2Fissues%2F10191%23issuecomment-315707719=02%
>7C01%7C%7C3246fdcb92214d77f08508d4ccfcd826%7Cfa7b1b5a7b34438794aed2c178dec
>ee1%7C0%7C0%7C636358833708383226=fDF8%2FwsOXbDNWL1qph6qd4o6U2uKFcyyF
>fULZDHna%2BE%3D=0
>om%2Ffacebook%2Freact%2Fissues%2F10191%23issuecomment-315707719=02%7C
>01%7C%7C3246fdcb92214d77f08508d4ccfcd826%7Cfa7b1b5a7b34438794aed2c178decee
>1%7C0%7C0%7C636358833708383226=fDF8%2FwsOXbDNWL1qph6qd4o6U2uKFcyyFfU
>LZDHna%2BE%3D=0>
>
>> On Jul 17, 2017, at 1:09 PM, Yishay Weiss 
>>wrote:
>> 
>> Does that rule out a reactjs component set (ala createjs)?
>> 
>> From: Harbs
>> Sent: Monday, July 17, 2017 12:47 PM
>> To: dev@flex.apache.org
>> Subject: Re: FYI: React appears to be a no-no
>> 
>> No.
>> 
>> I just thought this was newsworthy.
>> 
>>> On Jul 17, 2017, at 10:27 AM, Alex Harui 
>>>wrote:
>>> 
>>> I"m not following.  Do we currently have a required dependency on
>>>React?
>>> 
>>> -Alex
>>> 
>>> On 7/16/17, 6:19 AM, "Harbs"  wrote:
>>> 
 The incompatibility of React’s license is potentially significant for
 FlexJS.[1]
 
 
[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiss
ues
 
.apache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534
e63
 
772208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358079
641
 
383681=Ag6aXVH9z9XDazv6hpTakzzcNA%2BdIUBrCS1sYTLGTho%3D=
0
 
 
 
 
>>> 
>> 
>

Re: Moonshine 1.5.0 Release

[piotrz]

Hi,

I just post announce on Apache Flex facebook [1]! :)

[1] https://www.facebook.com/ApacheFlexSDK/posts/1100785523355723

Thanks,
Piotr 





-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Moonshine-1-5-0-Release-tp63237p63334.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [Falcon] operand stack underflow?

[Yishay Weiss]

This [1] is what I get when building DataBindingExample. Says build is 
successful but the following message suggests it is not:

[mxmlc] Exception in thread "main" java.lang.AssertionError: Unsupported 
property value: 1px solid #808080scanning for overrides: IUIBase

[1] https://paste.apache.org/STWV

From: Yishay Weiss
Sent: Monday, July 17, 2017 4:24 PM
To: dev@flex.apache.org
Subject: RE: [Falcon] operand stack underflow?

I’m actually able to build after running the following batch file:

cd \dev\flexjs\flex-falcon
git pull
call ant wipe-all
cd \dev\flexjs\flex-typedefs
call ant wipe
git pull
cd \dev\flexjs\flex-asjs
call ant super-clean
git pull
ant clean all


I am however getting a runtime error because of the following line in 
PortedPrintUI.js:

function() {this["border"] = ;

Which probably comes from basic -> defaults.css:

Button
{
   background-color: #f8f8f8;
   border: 1px solid #808080;
   border-radius: 2px;
   padding: 4px;
   margin: 0px;
}

I’ll try to create a simple test case.

From: Harbs
Sent: Monday, July 17, 2017 3:09 PM
To: dev
Subject: [Falcon] operand stack underflow?

I just updated flex-falcon and flex-asjs. After rebuilding everything, I’m 
getting the following error when compiling my app:

https://paste.apache.org/3wBr 

This is a new one for me…

Suggestions?

Harbs

RE: [Falcon] operand stack underflow?

[Yishay Weiss]

I’m actually able to build after running the following batch file:

cd \dev\flexjs\flex-falcon
git pull
call ant wipe-all
cd \dev\flexjs\flex-typedefs
call ant wipe
git pull
cd \dev\flexjs\flex-asjs
call ant super-clean
git pull
ant clean all


I am however getting a runtime error because of the following line in 
PortedPrintUI.js:

function() {this["border"] = ;

Which probably comes from basic -> defaults.css:

Button
{
   background-color: #f8f8f8;
   border: 1px solid #808080;
   border-radius: 2px;
   padding: 4px;
   margin: 0px;
}

I’ll try to create a simple test case.

From: Harbs
Sent: Monday, July 17, 2017 3:09 PM
To: dev
Subject: [Falcon] operand stack underflow?

I just updated flex-falcon and flex-asjs. After rebuilding everything, I’m 
getting the following error when compiling my app:

https://paste.apache.org/3wBr 

This is a new one for me…

Suggestions?

Harbs

Re: [Falcon] operand stack underflow?

[Harbs]

The previous error was what I got when using asconfigc in VS Code.

Here’s the stack trace when building using Ant:
https://paste.apache.org/Sy93 

> On Jul 17, 2017, at 3:09 PM, Harbs  wrote:
> 
> I just updated flex-falcon and flex-asjs. After rebuilding everything, I’m 
> getting the following error when compiling my app:
> 
> https://paste.apache.org/3wBr 
> 
> This is a new one for me…
> 
> Suggestions?
> 
> Harbs

[Falcon] operand stack underflow?

[Harbs]

I just updated flex-falcon and flex-asjs. After rebuilding everything, I’m 
getting the following error when compiling my app:

https://paste.apache.org/3wBr 

This is a new one for me…

Suggestions?

Harbs

[FlexJS XML] for each

[Harbs]

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 MXML ids and classNames - FLEX-35310

[piotrz]

Hi Alex,

That's a valid point and I think I'm willing to change my vote to have
localId. Let me understand fully this. If we introduce "localId" - 

- We will be able to have same id in different view - Introducing that new
field is less time consuming than doing solution which I vote for ?
- Compiler will shot us some warning if we have duplicate "id" ?

Thanks,
Piotr





-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63328.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FYI: React appears to be a no-no

[Harbs]

As Dave said, let’s see how this plays out at Facebook, but it’s currently not 
looking too great.[1]

My understanding is that it would preclude a reactjs component set, but I could 
be wrong.

[1]https://github.com/facebook/react/issues/10191#issuecomment-315707719 


> On Jul 17, 2017, at 1:09 PM, Yishay Weiss  wrote:
> 
> Does that rule out a reactjs component set (ala createjs)?
> 
> From: Harbs
> Sent: Monday, July 17, 2017 12:47 PM
> To: dev@flex.apache.org
> Subject: Re: FYI: React appears to be a no-no
> 
> No.
> 
> I just thought this was newsworthy.
> 
>> On Jul 17, 2017, at 10:27 AM, Alex Harui  wrote:
>> 
>> I"m not following.  Do we currently have a required dependency on React?
>> 
>> -Alex
>> 
>> On 7/16/17, 6:19 AM, "Harbs"  wrote:
>> 
>>> The incompatibility of React’s license is potentially significant for
>>> FlexJS.[1]
>>> 
>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues
>>> .apache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e63
>>> 772208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358079641
>>> 383681=Ag6aXVH9z9XDazv6hpTakzzcNA%2BdIUBrCS1sYTLGTho%3D=0
>>> >> pache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e6377
>>> 2208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635807964139
>>> 3686=KeNChB38k71gekwa0h%2Fq6P8P3VN%2FbB2TYzICzB%2BosTo%3D=0
 
>>> 
>>> 
>> 
> 

RE: FYI: React appears to be a no-no

[Yishay Weiss]

Does that rule out a reactjs component set (ala createjs)?

From: Harbs
Sent: Monday, July 17, 2017 12:47 PM
To: dev@flex.apache.org
Subject: Re: FYI: React appears to be a no-no

No.

I just thought this was newsworthy.

> On Jul 17, 2017, at 10:27 AM, Alex Harui  wrote:
>
> I"m not following.  Do we currently have a required dependency on React?
>
> -Alex
>
> On 7/16/17, 6:19 AM, "Harbs"  wrote:
>
>> The incompatibility of React’s license is potentially significant for
>> FlexJS.[1]
>>
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues
>> .apache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e63
>> 772208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358079641
>> 383681=Ag6aXVH9z9XDazv6hpTakzzcNA%2BdIUBrCS1sYTLGTho%3D=0
>> > pache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e6377
>> 2208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635807964139
>> 3686=KeNChB38k71gekwa0h%2Fq6P8P3VN%2FbB2TYzICzB%2BosTo%3D=0
>>>
>>
>>
>

Re: FYI: React appears to be a no-no

[Harbs]

No.

I just thought this was newsworthy.

> On Jul 17, 2017, at 10:27 AM, Alex Harui  wrote:
> 
> I"m not following.  Do we currently have a required dependency on React?
> 
> -Alex
> 
> On 7/16/17, 6:19 AM, "Harbs"  wrote:
> 
>> The incompatibility of React’s license is potentially significant for
>> FlexJS.[1]
>> 
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues
>> .apache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e63
>> 772208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358079641
>> 383681=Ag6aXVH9z9XDazv6hpTakzzcNA%2BdIUBrCS1sYTLGTho%3D=0
>> > pache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e6377
>> 2208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635807964139
>> 3686=KeNChB38k71gekwa0h%2Fq6P8P3VN%2FbB2TYzICzB%2BosTo%3D=0
>>> 
>> 
>> 
> 

Re: FYI: React appears to be a no-no

[Alex Harui]

I"m not following.  Do we currently have a required dependency on React?

-Alex

On 7/16/17, 6:19 AM, "Harbs"  wrote:

>The incompatibility of React’s license is potentially significant for
>FlexJS.[1]
>
>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues
>.apache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e63
>772208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636358079641
>383681=Ag6aXVH9z9XDazv6hpTakzzcNA%2BdIUBrCS1sYTLGTho%3D=0
>pache.org%2Fjira%2Fbrowse%2FLEGAL-319=02%7C01%7C%7C4c6a9d8c95534e6377
>2208d4cc4d45db%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635807964139
>3686=KeNChB38k71gekwa0h%2Fq6P8P3VN%2FbB2TYzICzB%2BosTo%3D=0
>>
>
>

Re: [FlexJS] Falcon AsJS Mismatch?

[Alex Harui]

I pushed a few more changes.  Hopefully nothing else broke.

-Alex

On 7/16/17, 8:52 AM, "Harbs"  wrote:

>I wasn’t complaining. I was sympathizing.
>
>If I knew how, I’d help.
>
>Harbs
>
>> On Jul 16, 2017, at 6:30 PM, Alex Harui 
>>wrote:
>> 
>> Someone else is welcome to take over.  This stuff is not something I
>>enjoy
>> doing at all.
>> 
>> -Alex
>> 
>> On 7/16/17, 5:17 AM, "Harbs" >> wrote:
>> 
>>> Is this with Alex’s latest changes?
>>> 
>>> These backslash escapes seem really difficult to get right… :-(
>>> 
 On Jul 16, 2017, at 2:41 PM, yishayw  wrote:
 
 Looks like falcon is incompatible with TabStopsPropety.as in TLF. When
 initializing that file I'm getting the following RTE:
 
 Uncaught syntax error: Invalid regular expression: missing /
 
 which originates in TabStopsProperty.as:191
 
private static const _escapeBackslashRegex:RegExp = //g;
 
 
 which transpiles to TabStopsProperty.js:143
 
 
 
 
org.apache.flex.textLayout.property.TabStopsProperty._escapeBackslashRe
ge
 x =
 /\/g;
 
 
 
 
 
 --
 View this message in context:
 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-
fl 

 ex-development.247.n4.nabble.com

%2FFlexJS-Falcon-AsJS-Mismatch-tp6329
 
6.html=02%7C01%7C%7C7636647c1c22433fc7f508d4cc44ab08%7Cfa7b1b5a7b3
44
 
38794aed2c178decee1%7C0%7C0%7C636358042688036466=ZYSsWDWEs54Zs4sX
IY
 k2SrHt%2FnurGBhIb8VYAH6zQtM%3D=0
 Sent from the Apache Flex Development mailing list archive at
 Nabble.com 
.
>

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Justin Mclean]

Hi,

> "Slightly fatter" might be acceptable.  Your changes looked like a lot of
> code.  

Im not sure you are looking at the same changes I am.

 All that was added was:
-  the TOP, BOTTOM, LEFT, RIGHT constants 
- an if statement with a number of else ifs to work out the positioning
- changing this line:
pt = new Point(comp.width, comp.height);
to this:
pt = new Point(comp.width/xFactor, comp.height/yFactor);

That seems reasonably slim to me. What is your definition of “slightly fatter”?

Thanks,
Justin

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Alex Harui]

Seems reasonable to add a check to see if the function body is for a
static method.

-Alex

On 7/16/17, 11:25 PM, "Harbs"  wrote:

>A directive could be a solution.
>
>But I think this is an issue with any static method. If a closure is used
>inside a static method, or a function declared inside a static method, it
>should not use Language.closure.
>
>FWIW, the Google compile complains about “this” being used in a static
>method as well:
>
>[mxmlc] Jul 16, 2017 7:26:08 PM
>com.google.javascript.jscomp.LoggerErrorManager println
>[mxmlc] WARNING:
>/Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingExamp
>le/bin/js-debug/org/apache/flex/utils/callLater.js:35: WARNING -
>dangerous use of this in static method org.apache.flex.utils.callLater
>[mxmlc]   
>setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>'makeCalls'), 0);
>
>Package level functions should be treated as static methods.
>
>It might not be a bad idea to add a directive to allow developers to
>avoid Language.closure calls at will, but I think the “correct” general
>solution is to never output Language.closure in static and package level
>functions.
>
>> On Jul 17, 2017, at 9:16 AM, Alex Harui 
>>wrote:
>> 
>> I don't see any current way to suppress the Language.closure.  Without
>> flow-analysis, I'm not sure the compiler can tell.  It could guess that
>> the identifier is a parameter, but the parameter variable could be
>> assigned within the function body.
>> 
>> We could add a new directive like @flexjsisclosure or something like
>>that.
>> 
>> Thoughts?
>> -Alex
>> 
>> On 7/16/17, 10:05 AM, "Harbs"  wrote:
>> 
>>> I figured out the problem.
>>> 
>>> org.apache.flex.utils.callLater has the following code:
>>> setTimeout(makeCalls, 0);
>>> 
>>> That compiles to:
>>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>>> 'makeCalls'), 0);
>>> 
>>> When Language.closure is called, it messes up the scope of the calls
>>> variable and subsequent calls to makeCalls step on each other. I
>>>believe
>>> this is because makeCalls is bound to the package object of the
>>>callLater
>>> function.
>>> 
>>> Is there any way to prevent rewriting of function calls to
>>> Language.closure?
>>> 
>>> If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
>>> "setTimeout(makeCalls, 0);", it works like I’d expect it to.
>>> 
>>> Thanks,
>>> Harbs
>>> 
 On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
 
 Interesting to note:
 
 Adding a number of callLater() calls resulted in only the first one
 being called in JS. I did not try as a SWF.
>>> 
>> 
>

Re: FlexJS MXML ids and classNames - FLEX-35310

[Alex Harui]

Well, it makes no sense to me to invent some new property name that sets
the "id" of an HTMLElement.  I would think we'd get a ton of questions
about it.  If I"m the only one who thinks that, then I'll stop arguing
against it.  I thought the consensus upthread was to add localId.

-Alex


On 7/16/17, 11:16 AM, "piotrz"  wrote:

>Josh,
>
>In general if I correct understand that was your idea. I think it is the
>simpler solution where we
>- Stop set up "id" to HTML id
>- Introduce new property which will set up it in html
>
>+1 for Josh's idea.
>
>Thanks,
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-tp543
>61p63315.html=02%7C01%7C%7C93dc53d5c28f4e49156408d4cc7970af%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636358269329946292=APogtmBEyf0%2
>BbZVWxl5H%2B%2BT65fTWXDS%2Fys9Ph3aQUmU%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Harbs]

A directive could be a solution.

But I think this is an issue with any static method. If a closure is used 
inside a static method, or a function declared inside a static method, it 
should not use Language.closure.

FWIW, the Google compile complains about “this” being used in a static method 
as well:

[mxmlc] Jul 16, 2017 7:26:08 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[mxmlc] WARNING: 
/Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingExample/bin/js-debug/org/apache/flex/utils/callLater.js:35:
 WARNING - dangerous use of this in static method 
org.apache.flex.utils.callLater
[mxmlc]   setTimeout(org.apache.flex.utils.Language.closure(makeCalls, 
this, 'makeCalls'), 0);

Package level functions should be treated as static methods.

It might not be a bad idea to add a directive to allow developers to avoid 
Language.closure calls at will, but I think the “correct” general solution is 
to never output Language.closure in static and package level functions.

> On Jul 17, 2017, at 9:16 AM, Alex Harui  wrote:
> 
> I don't see any current way to suppress the Language.closure.  Without
> flow-analysis, I'm not sure the compiler can tell.  It could guess that
> the identifier is a parameter, but the parameter variable could be
> assigned within the function body.
> 
> We could add a new directive like @flexjsisclosure or something like that.
> 
> Thoughts?
> -Alex
> 
> On 7/16/17, 10:05 AM, "Harbs"  wrote:
> 
>> I figured out the problem.
>> 
>> org.apache.flex.utils.callLater has the following code:
>> setTimeout(makeCalls, 0);
>> 
>> That compiles to:
>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>> 'makeCalls'), 0);
>> 
>> When Language.closure is called, it messes up the scope of the calls
>> variable and subsequent calls to makeCalls step on each other. I believe
>> this is because makeCalls is bound to the package object of the callLater
>> function.
>> 
>> Is there any way to prevent rewriting of function calls to
>> Language.closure?
>> 
>> If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
>> "setTimeout(makeCalls, 0);", it works like I’d expect it to.
>> 
>> Thanks,
>> Harbs
>> 
>>> On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
>>> 
>>> Interesting to note:
>>> 
>>> Adding a number of callLater() calls resulted in only the first one
>>> being called in JS. I did not try as a SWF.
>> 
> 

Re: git commit: [flex-asjs] [refs/heads/develop] - added simple positioning to tool tip / make tool tip not react to mouse events

[Alex Harui]

"Slightly fatter" might be acceptable.  Your changes looked like a lot of
code.  Did you rule out using CSS to position the tooltip?

We want the examples to be as small as possible to attract users.

-Alex

On 7/14/17, 6:31 PM, "Justin Mclean"  wrote:

>Hi,
>
>Alex you said this about the latest changes:
>> Anyway, this is quite a bit of new code.  The old bead should have been
>> preserved and given a name like ToolTipsOnRightBottomBead and the
>>existing
>> examples updated to use it.
>
>But before you said:
>>Maybe the default tooltip bead should be slightly fatter and have x/y
>>offsets or some other way to dictate the relative position.
>
>So which is it?
>
>Why is it an issue that the examples are using the new (working) tool
>tip? Especially when the default is bottom right so it will look the same.
>
>Thanks,
>Justin

Re: [FlexJS] Avoiding Language.closure (was Re: [FlexJS] Debugging package)

[Alex Harui]

I don't see any current way to suppress the Language.closure.  Without
flow-analysis, I'm not sure the compiler can tell.  It could guess that
the identifier is a parameter, but the parameter variable could be
assigned within the function body.

We could add a new directive like @flexjsisclosure or something like that.

Thoughts?
-Alex

On 7/16/17, 10:05 AM, "Harbs"  wrote:

>I figured out the problem.
>
>org.apache.flex.utils.callLater has the following code:
>setTimeout(makeCalls, 0);
>
>That compiles to:
>setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this,
>'makeCalls'), 0);
>
>When Language.closure is called, it messes up the scope of the calls
>variable and subsequent calls to makeCalls step on each other. I believe
>this is because makeCalls is bound to the package object of the callLater
>function.
>
>Is there any way to prevent rewriting of function calls to
>Language.closure?
>
>If "setTimeout(makeCalls, 0);" is cross-compiled exactly to:
>"setTimeout(makeCalls, 0);", it works like I’d expect it to.
>
>Thanks,
>Harbs
>
>> On Jul 16, 2017, at 3:46 PM, Harbs  wrote:
>> 
>> Interesting to note:
>> 
>> Adding a number of callLater() calls resulted in only the first one
>>being called in JS. I did not try as a SWF.
>