Re: [FlexJS] hard coded event names

Hi, > I was under the assumption that every constant adds an alias to the output. That doesn’t seem to be the case as the compiler can optimise this - that’s a good think. Leet like get to make a cake and eat it. > But again, I'd prefer that we don't spend time on this topic until after the >

Re: [FlexJS] hard coded event names

Again, interesting topic, but maybe table it until after the release? I was under the assumption that every constant adds an alias to the output. Otherwise data binding to constants would not work after variable renaming. But again, I'd prefer that we don't spend time on this topic until after

Re: [FlexJS] hard coded event names

Hi, > Like I already said; constants add much more bulk to the JS source code. Try > it and you’ll see… I’ve tried it and they don’t, but perhaps I’m missing something? Looking some AS code like so: var result1:String = "One" + "Two" + "Three"; var result2:String = ONE + TWO + THREE; var

Re: [FlexJS] hard coded event names

Harbs, I think that is only for debug. I don't think they should add bulk to the release code. At least they do not in the default settings for GCC optimisation. You will see the definition of the constant only once and inline replacement is used for the value (with a short name global variable)

Re: [FlexJS] hard coded event names

Huh? Why would tests be necessary? Like I already said; constants add much more bulk to the JS source code. Try it and you’ll see… > On May 23, 2017, at 5:53 PM, Justin Mclean wrote: > > Have you done any tests to show this is the case?

Re: [FlexJS] hard coded event names

Hi, > I don't think this is a release critical issue, but it is an interesting > topic. Agreed not for this release anyway but coming up with a common pattern would be useful. > AFAICT, strings optimize better than constant lookups. Have you done any tests to show this is the case? > The

Re: [FlexJS] hard coded event names

On 5/23/17, 5:48 AM, "Harbs" wrote: > >The FlexJS style of defining constants are to define them where they are >used rather than creating new Event classes simply for defining the >constants. (i.e. Timer.TIMER rather than TimerEvent.TIMER) This statement is a key

Re: [FlexJS] hard coded event names

The current compiler setup makes use of static constants add considerably more bulk to the compiled code than string literals. It might be possible to make the Google Compiler do a better job, but as it stands, we’re better off with string literals than constants. The FlexJS style of defining

Re: [FlexJS] hard coded event names

So, what was wrong with that practice? I sort of got used to it and it makes maintaining and extending quite easy. I really dislike these constant-graves ;-) Chris Am 23.05.17, 12:56 schrieb "Justin Mclean" : Hi, > Didn’t in the past most Event types

Re: [FlexJS] hard coded event names

Hi, > Didn’t in the past most Event types contain the constants inside themselves? Yep in the Flex SDK that’s the case. Thanks, Justin

Re: [FlexJS] hard coded event names

Hi Justin, Didn’t in the past most Event types contain the constants inside themselves? Chris Am 23.05.17, 12:14 schrieb "Justin Mclean" : Hi, > If you add a bunch of constants to those 2, you end up bloating them. Still seems a higher cost to

Re: [FlexJS] hard coded event names

Hi, > If you add a bunch of constants to those 2, you end up bloating them. Still seems a higher cost to have the same thing mentioned dozens of times. Not measured the exact performance impact however. > App developers should get code hinting in mxml via metadata so typos are > mitigated. I

Re: [FlexJS] hard coded event names

this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-hard-coded-event-names-tp61769p61770.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] hard coded event names

Hi, In the Flex SDK we have a large number of event names hard coded. Is there any reason (performance or otherwise) for coding in this style? Usually I would define them as consts in a single place and refer to that. Are we assuming the compiler will optimise this and that no one will miss