Hi Erik,
Well, this renaming issue is coming from an actual scenario that runs
correctly when not minified. I think what you are showing is that the
code-flow analyzer contributes to the renaming logic. In this actual test
case, someFunction is called from an event handler, so maybe the renaming
logic can’t follow the code-flow in those situations, especially because
lots of things are set up via the MXML data structure.
However, if we can just prevent renaming, I think that will also work.
Having to define both a dummy prototype slot with @expose as well as the
defineProperties seems redundant to me, but I think that’s the route to
take, so thanks for finding that. I’ll see if I can get to the finish
line with that.
One more question: Defining a slot without a value generates warnings
from GCC when called from FalconJX. IOW, adding this:
/**
* @expose
*/
org_apache_flex_utils_BinaryData.prototype.productService;
Will result in:
WARNING - Suspicious code. The result of the 'getprop' operator is not
being used.
I’m not sure why we get this warning in FalconJX but not in the GCC
Service UI or from the GCC command line. And also @expose is deprecated.
But if you’re ok with using @expose and finding a way to shut off those
warnings, I’ll go with that.
Thanks for the help,
-Alex
On 4/6/15, 2:33 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>Alex,
>
>I think what you're seeing is an artifact of the way you've set up
>your example... You don't instantiate the object and never reference
>the property outside of the class' internals. WIth such a minimal
>case, that basically doesn't execute, the compiler thinks it can be
>smart and 'optimize' away vital parts of the code... If I rework your
>example a bit to make it feel more 'real world' to the compiler:
>
>
>
>/**
> * @constructor
> */
>var org_apache_flex_utils_BinaryData = function () {
>
> /**
> * @private {number}
> */
> this.productService_;
>
>}
>
>org_apache_flex_utils_BinaryData.prototype.someFunction = function() {
> console.log(this.productService);
>};
>
>Object.defineProperties(org_apache_flex_utils_BinaryData.prototype, {
> productService: {
> /** @this {org_apache_flex_utils_BinaryData} */
> get: function() {
> return this.productService_;
> },
> /** @this {org_apache_flex_utils_BinaryData} */
> set: function(value) {
> this.productService_ = value + 10;
> }
> }
>});
>
>var binaryData = new org_apache_flex_utils_BinaryData();
>
>binaryData.productService = 100;
>
>binaryData.someFunction();
>
>
>
>... You get, without errors or warnings:
>
>
>
>'use strict';function
>a(){}Object.defineProperties(a.prototype,{a:{get:function(){return
>this.b},set:function(c){this.b=c+10}}});var b=new
>a;b.a=100;console.log(b.a);
>
>
>
>This code does actually execute and it gives the expected 110, showing
>the setter is called and the 'defineProperties' is not simply ignored.
>You see the property is renamed to the same string 'everywhere', so
>the compiler knows what it is and how to handle it.
>
>In this example you can prevent the renaming by declaring the property
>with an @expose annotation on the object's prototype just before
>calling 'Object.defineProperties':
>
>
>
>/**
> * @expose
> */
>org_apache_flex_utils_BinaryData.prototype.productService;
>
>
>
>Which, combined, gives a compiled output:
>
>
>
>'use strict';function
>a(){}Object.defineProperties(a.prototype,{productService:{get:function(){r
>eturn
>this.a},set:function(c){this.a=c+10}}});var b=new
>a;b.productService=100;console.log(b.productService);
>
>
>
>Isn't that what you're looking for?
>
>EdB
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
