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 the release.
Thanks,
-Alex
On 5/23/17, 8:14 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>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 result3:String = Outside.ONE + Outside.TWO + Outside.THREE;
>var duplicate1:String = "One" + "Two" + "Three";
>var duplicate2:String = ONE + TWO + THREE;
>var duplicate3:String = Outside.ONE + Outside.TWO + Outside.THREE;
>
>
>On the debug side we get:
>
>In Outside.js:
> Outside.ONE = "One”;
> Outside.TWO = "Two”;
> Outside.THREE = "Three”;
>
>In main program:
> StaticConst.ONE = "One”;
> StaticConst.TWO = "Two”;
> StaticConst.THREE = "Three";
>
> var /** @type {string} */ result1 = "One" + "Two" + "Three";
> var /** @type {string} */ result2 = StaticConst.ONE + StaticConst.TWO +
>StaticConst.THREE;
> var /** @type {string} */ result3 = Outside.ONE + Outside.TWO +
>Outside.THREE;
> var /** @type {string} */ duplicate1 = "One" + "Two" + "Three";
> var /** @type {string} */ duplicate2 = StaticConst.ONE +
>StaticConst.TWO + StaticConst.THREE;
> var /** @type {string} */ duplicate3 = Outside.ONE + Outside.TWO +
>Outside.THREE;
>
>There doesn’t seem to be any optimisation in any of the three methods for
>debug and in fact using strings vs static const looks to increases the
>memory use of the code as you have multiple instances of “one”, “two”,
>“three”.It may do some optimisation at runtime I guess. But at a casual
>glance hard coding duplicate strings seem worse off although I agree it
>doesn’t have the object property lookup cost. I can’t see that would be
>significant.
>
>For release we get all three get treated exactly same way as Greg pointed
>out. In fact it goes as far as to optimise them all to be the same
>variable and use that single variable rather than have 6 different
>variables.
>
>So I can’t really see any reason for hard coding this in the SDK as it
>seems you get exactly the same results in production and probably better
>off in debug.
>
>Thanks,
>Justin
