On 10/5/16, 11:13 AM, "Harbs" wrote:
>And what’s the reason we’re not just using Foo.someOtherStaticProperty?
>Is this a getter issue?
Getters/Setters need to be defined via Object.defineProperty. It is the
only way to access a function via a property name (without using
parentheses). IOW
On 10/5/16, 11:10 AM, "Harbs" wrote:
>So, this is only an issue for static functions and vars? Constants should
>be fine. Right?
Actually, only for static getters and setters. The output for vars,
consts and functions are not being changed at all and GCC will rename them
and set up aliases fo
And what’s the reason we’re not just using Foo.someOtherStaticProperty? Is this
a getter issue?
On Oct 5, 2016, at 9:08 PM, Alex Harui wrote:
>
>
> On 10/5/16, 10:43 AM, "Harbs" wrote:
>
>> I have not been following this discussion very well, so I’m not sure I
>> got the issue, but will th
So, this is only an issue for static functions and vars? Constants should be
fine. Right?
On Oct 5, 2016, at 9:08 PM, Alex Harui wrote:
>
>
> On 10/5/16, 10:43 AM, "Harbs" wrote:
>
>> I have not been following this discussion very well, so I’m not sure I
>> got the issue, but will this prev
On 10/5/16, 10:43 AM, "Harbs" wrote:
>I have not been following this discussion very well, so I’m not sure I
>got the issue, but will this prevent optimization of minimized code which
>accesses static properties?
I think I have discovered that static getters/setters were never getting
renamed
I have not been following this discussion very well, so I’m not sure I got the
issue, but will this prevent optimization of minimized code which accesses
static properties?
On Oct 5, 2016, at 7:26 PM, Alex Harui wrote:
> Anyway, I wanted to see if anyone objects to this change before I push it
This seems like a reasonable enough workaround. I really wish GCC weren't
always giving us so many issues. I know many of them are "by design", but
it gets frustrating very quickly.
- Josh
On Wed, Oct 5, 2016 at 9:26 AM, Alex Harui wrote:
> So I replaced the @expose usage with @export on Access
So I replaced the @expose usage with @export on Accessors and looked into
why things don't work when you do that. It probably is a bug in GCC, but
I saw an article where GCC developers say that all static definitions are
considered separate "globals" and not properties of something. It is an
inte
I pushed changes to generate exportSymbol/exportProperty for certain
metadata names. It fixed the ReflectionTests in GenericTests.
I also modified ObservedBugs so that it wouldn't get optimized away. IMO,
folks will just have to realize that certain patterns can be optimized
away. It might be p
On 10/3/16, 10:51 AM, "Greg Dove" wrote:
>That sounds great Alex. Good sleuthing. As keep as3 metadata provides for
>specific metadata don't you think this could be default for the class
>members with specific kept metadata? Given that the only reason for
>keeping
>it would be for reflection,
That sounds great Alex. Good sleuthing. As keep as3 metadata provides for
specific metadata don't you think this could be default for the class
members with specific kept metadata? Given that the only reason for keeping
it would be for reflection, I mean? I will be happy with the option here no
ma
Update: Turns out that FalconJX already calls GCC with
--generate-exports, and methods are being exported in the js-release
version. What it looks like to me is that for the one case I am debugging
(ReflectionTesterTest), the setUpBeforeClass method is removed by GCC dead
code removal since there
On 10/1/16, 12:37 PM, "Greg Dove" wrote:
>Sorry I did not have time to read up on this yet.
>
>If --generate-exports can somehow restore that naming retention for public
>static members annotated with '@export' then that will be a great starting
>point as an option to switch this on or off when
Sorry I did not have time to read up on this yet.
If --generate-exports can somehow restore that naming retention for public
static members annotated with '@export' then that will be a great starting
point as an option to switch this on or off when needed.
If I consider where I have used refllect
Change GoogDocEmitter got rid of the warnings but broke GenericTests for
now.
I will next try --generate-exports, but I'm thinking we want to allow
control at the file and property/method level.
Thoughts?
-Alex
On 9/30/16, 12:27 PM, "Greg Dove" wrote:
>Thanks for the explanation!
>I guess I mi
Thanks for the explanation!
I guess I missed the distinction with the accessors, but I had remembered
the 'solution' and just assumed it was appropriate when it 'worked' for
static variables and methods (not realizing the other consequences).
In any case it appears that @export does not prevent re
IMO, there are two separate issues.
I think Josh found that static accessors couldn't be accessed via normal
code "ClassName.propertyName". I ran into this for instance accessors as
well. The instance accessors are defined in a Object.defineProperty call
separate from the usual ClassName.prototy
I read that link, it's very helpful. It seems that this is going to be a
challenge. I suggest you revert that as you suggested.
Josh discovered this originally for static accessors I think (the fact that
@export does not prevent renaming on statics and @expose was the only other
option that seemed
Alex, @export did not work for me on any static members. You cannot reflect
into the field names unless you use @expose.
You can double check this via generictests reflection tests.
-Greg
[sent from my phone]
On 1/10/2016 5:21 AM, "Alex Harui" wrote:
>
>
> On 9/29/16, 11:36 PM, "Alex Harui" w
On 9/29/16, 11:36 PM, "Alex Harui" wrote:
>
>Now that I got rid of the circularity in Ibead/Istrand I am also getting a
>ton of warnings that say:
>
> WARNING - incomplete alias created for namespace goog
I think is is being caused by the change from @export to @expose [1]
What was the scenar
On 9/28/16, 11:43 AM, "Alex Harui" wrote:
>
>
>On 9/28/16, 11:23 AM, "Greg Dove" wrote:
>
>>OT: I am getting a lot of warnings in the GCC release build phase. I
>>recall
>>you mentioning something in the past about this being related to GCC
>>versions - is there anything I can do to address this
On 9/28/16, 11:36 AM, "Greg Dove" wrote:
>Thanks for clarifying. I see that you mentioned that originally now :)
>I think if GCC is smart enough to follow the indirection between those
>reflection field names and all possible uses of reflection it would be
>quite impressive. I don't think it wo
On 9/28/16, 11:23 AM, "Greg Dove" wrote:
>OT: I am getting a lot of warnings in the GCC release build phase. I
>recall
>you mentioning something in the past about this being related to GCC
>versions - is there anything I can do to address this?
Every once in a while, we have to upgrade to the
Thanks for clarifying. I see that you mentioned that originally now :)
I think if GCC is smart enough to follow the indirection between those
reflection field names and all possible uses of reflection it would be
quite impressive. I don't think it works as is, because if it wasn't for
some static f
On 9/28/16, 11:19 AM, "Greg Dove" wrote:
>I hadn't investigated any of this, just wondered about it I will check the
>reflection results today.
>I had actually assumed that @export and @expose explicitly prevented
>renaming, but also had not checked this.
>
Maybe I wasn't clear.
@export and @
OT: I am getting a lot of warnings in the GCC release build phase. I recall
you mentioning something in the past about this being related to GCC
versions - is there anything I can do to address this?
On Thu, Sep 29, 2016 at 7:19 AM, Greg Dove wrote:
> I hadn't investigated any of this, just wo
I hadn't investigated any of this, just wondered about it I will check the
reflection results today.
I had actually assumed that @export and @expose explicitly prevented
renaming, but also had not checked this.
On Thu, Sep 29, 2016 at 7:13 AM, Alex Harui wrote:
> In fact, when I last touched i
In fact, when I last touched it, Reflection was optional. Unless you
actually use a reflection API (whose code path access
FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
minified results. Probably worth verifying that is still true.
What I don't know is whether dead co
"reflection support could be opt-in (or opt-out)"
On reflection (pun unintended) maybe that is not sensible, given it is
baked in to the framework classes. If GCC does dead-code elimination, maybe
that does the job anyhow.
On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove wrote:
> Alex, I had also
Alex, I had also considered the same idea of doing the qualifiedName
splitting in the reflection data because I think you would reduce a lot of
long string variation in the GCC release build simply by doing
'org.apache.flex.'+'Package.'+'ClassName' etc
Isn't using the reflection member definition
n which you can fill hours with
unexpectable JavaScript results.
Chris
Von: Alex Harui
Gesendet: Mittwoch, 28. September 2016 19:29:22
An: dev@flex.apache.org
Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript
language feature: Optio
On 9/28/16, 8:37 AM, "Josh Tynjala" wrote:
>For core classes like Number, Array, Boolean, etc. what looks like a cast
>is actually a function call. There's a global function named Array, and
>calling that takes precedence over casting.
>
>Personally, I think we should avoid breaking changes lik
On 9/28/16, 3:25 AM, "Harbs" wrote:
>I like this idea and would propose taking it one step further:
>
>Currently transpiled javascript has fully qualified class names for
>pretty much everything. This is difficult for closure to minimize
>completely. I’d really like to have some way to “export”
.sephiroth.it/weblog/archives/2007/03/
> actionscript_4_import_alias_where_is.php
>
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/Falcon-Proposal-for-new-
> ActionScript-language-feature-Optionally-rename-an-import-
> tp55355p55400.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
ctionscript for different reasons, and I am
> > > > comfortable with liking both (some people tend to be more polar in
> > their
> > > > views!).
> > > > I personally would also welcome these features in actionscript. But I
> > do
> > > > wonder whether it helps or hinders the long term
247.n4.nabble.com/Falcon-Proposal-for-new-ActionScript-language-feature-Optionally-rename-an-import-tp55355p55400.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
o other exceptions, that really really anoy me and
probably others too.
Chris
Von: Josh Tynjala
Gesendet: Mittwoch, 28. September 2016 02:50:12
An: dev@flex.apache.org
Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript
language feature:
I like this idea and would propose taking it one step further:
Currently transpiled javascript has fully qualified class names for pretty much
everything. This is difficult for closure to minimize completely. I’d really
like to have some way to “export” class names as well as “import” to define
and then.
>
>
> Chris
>
>
> Von: Josh Tynjala
> Gesendet: Dienstag, 27. September 2016 16:59:33
> An: dev@flex.apache.org
> Betreff: [Falcon] Proposal for new ActionScript language feature:
> Optionally rename an import
>
> I would lik
generics
> on
> > > top
> > > > of JavaScript :)
> > > >
> > > > I think the Parser part would be the part I can help with ... I like
> > > Antlr
> > > > (even the old versions) I should manage to adjust the parser grammar
> to
> >
should manage to adjust the parser grammar to
> > > produce some additional AST nodes. It was more the other part that I
> was
> > > worried about. Seems together this would be a huge thing. Espsecially
> > > because I noticed people drop all their predudices against Flex as soon
> > as
Couple of thoughts:
Yes, ActionScript is going to be compared against other languages. We
simply don't want to make that the decision point. Developer productivity
is what we need to deliver. MXML and AS are our starting point because
that is what we own. Really, if folks wanted to glue their
lex as soon
> as
> > you state: "We're more or less the same as TypeScript, but we have loads
> of
> > well established libraries to use" ... currently the thing I always here
> is
> > "but Typescript has Generics ... and I like Generics" I would s
ays here is
> "but Typescript has Generics ... and I like Generics" I would so
> desperately like to get rid of that reply ;-)
>
>
> Chris
>
>
> Von: Alex Harui
> Gesendet: Dienstag, 27. September 2016 22:25:46
> An: dev@flex
Harui
Gesendet: Dienstag, 27. September 2016 22:25:46
An: dev@flex.apache.org
Betreff: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language
feature: Optionally rename an import)
It should be possible to add compile-time language features like Generics.
There might be issues around r
a good idea to start collecting features as we wouldn't want to
>do an AS5, AS6, ... AS2000 every now and then.
>
>
>Chris
>
>____________
>Von: Josh Tynjala
>Gesendet: Dienstag, 27. September 2016 16:59:33
>An: dev@flex.apache.org
>Be
On 9/27/16, 9:19 AM, "Josh Tynjala" wrote:
>You are definitely correct that Flash Builder does not necessarily pick up
>code hinting from the same SDK that you're using to compile the project.
>However, as I understand it, FB integrates with the AIR SDK with ASC 2.0
>that is installed inside an
You are definitely correct that Flash Builder does not necessarily pick up
code hinting from the same SDK that you're using to compile the project.
However, as I understand it, FB integrates with the AIR SDK with ASC 2.0
that is installed inside an Eclipse plugin at this location:
/eclipse/plugins
Fine with me.
I would prefer that the basic component set of FlexJS not use this
feature. It might mess up ASDoc and some other places. I'm not clear
that FB 4.7 picks up the code-hinting from the SDK you are using. Also, I
often use grep when coding and aliases will mess up my results.
But fo
es as we wouldn't want to do an AS5, AS6, ...
AS2000 every now and then.
Chris
Von: Josh Tynjala
Gesendet: Dienstag, 27. September 2016 16:59:33
An: dev@flex.apache.org
Betreff: [Falcon] Proposal for new ActionScript language feature: Optionally
rename an
I would like to propose a new feature for the ActionScript language in the
Apache Flex "Falcon" compiler. It would be nice if developers could
(optionally) rename an import.
Background
==
Normally when you import a class, you can reference the name of the class,
without the package (unles
51 matches
Mail list logo
