I'm assuming (but can't find any directly relevant links ;-) that this is because the JS spec (ECMA) says that an object's properties should be addressable with quoted AND dotted notification (i.e. obj['prop'] and obj.prop). If the compiler renamed the property, it would remove the ability to use quoted access...
EdB On Mon, Apr 6, 2015 at 3:36 PM, Alex Harui <aha...@adobe.com> wrote: > Hi Erik, > > That’s interesting. I’ll try that site. I would have expected the > compiler to rename position to some one or two-letter variable. Can you > tell me why it didn’t? > > -Alex > > On 4/6/15, 5:17 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >>Alex, >> >>I used 'http://closure-compiler.appspot.com/' with this input: >> >>// ==ClosureCompiler== >>// @compilation_level ADVANCED_OPTIMIZATIONS >>// @warning_level VERBOSE >>// @language ECMASCRIPT5_STRICT >>// ==/ClosureCompiler== >> >>'use strict'; >> >>/** >> * @constructor >> */ >>var org_apache_flex_utils_BinaryData = function () {} >> >>/** >> * @private >> * @type {number} >> */ >>org_apache_flex_utils_BinaryData.prototype.position_ = 0; >> >>Object.defineProperties(org_apache_flex_utils_BinaryData.prototype, { >> position: { >> /** @this {org_apache_flex_utils_BinaryData} */ >> get: function() { >> return this.position_; >> }, >> /** @this {org_apache_flex_utils_BinaryData} */ >> set: function(value) { >> this.position_ = value + 10; >> } >> } >>}); >> >>var binaryData = new org_apache_flex_utils_BinaryData(); >>binaryData.position = 100; >>console.log(binaryData.position); >> >>And I got this output (no errors, no warnings): >> >>'use strict';function >>a(){}a.prototype.a=0;Object.defineProperties(a.prototype,{position:{get:fu >>nction(){return >>this.a},set:function(c){this.a=c+10}}});var b=new >>a;b.position=100;console.log(b.position); >> >>What about the above output isn't what you expect? >> >>EdB >> >> >> >>On Mon, Apr 6, 2015 at 9:25 AM, Erik de Bruin <e...@ixsoftware.nl> wrote: >>> Have you tried it without the quotes around the property name in >>> Object.defineProperties? >>> >>> Also, if you're looking to prevent renaming by the GCC, you may want to >>>look >>> into the use of 'externs' files: >>> >>> >>>https://developers.google.com/closure/compiler/docs/api-tutorial3#externs >>> >>> EdB >>> >>> >>> >>> On Mon, Apr 6, 2015 at 8:18 AM, Alex Harui <aha...@adobe.com> wrote: >>>> Thanks for the suggestion. It didn’t seem to help. I’ve grepped the >>>>GCC >>>> code and didn’t see any attempt to handle defineProp. >>>> >>>> I think the issue is that GCC doesn’t expect code in the >>>>defineProperties >>>> functions to be referencing other functions in the class and vice >>>>versa. >>>> >>>> For example, this method references productService which is defined in >>>>the >>>> Object.defineProperties: >>>> >>>> /** >>>> * @private >>>> */ >>>> FlexJSStore.prototype.startService = function() { >>>> this.productService.send(); >>>> }; >>>> >>>> Object.defineProperties(FlexJSStore.prototype, { >>>> 'productService': { >>>> >>>> The optimizer renames “this.productServices.send()” to something like >>>> “this.Jj.send()”. It doesn’t seem to know about the defineProperties >>>> structure and that there is a non-renamable property called >>>> ‘productService’ so it uses a renaming variable like “Jj”. >>>> >>>> >>>> Putting all of the functions on the prototype slots would allow the >>>> optimizer to rename everything together. But we’d still need a way to >>>> teach GCC that the properties in the defineProperties structure can’t >>>>be >>>> renamed. GCC has deprecated @expose. It appears to be trying to be >>>>smart >>>> about use of string literals as a hint as to what can’t be renamed, >>>>but it >>>> isn’t very cautious. Use of ‘productService’ in the MXML output array >>>> won’t prevent renaming. It probably has to be a more direct usage off >>>>of >>>> a reference to the class or instance. There appears to be a blacklist >>>> Regex you can use to prevent renaming as well. It might be possible >>>>for >>>> the compiler to build out that regex. >>>> >>>> >>>> Thanks, >>>> -Alex >>>> >>>> On 4/4/15, 11:36 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >>>> >>>>>Alex, >>>>> >>>>>When working with Object.definePropert(y)(ies), did you experiment >>>>>using with the setting: >>>>> >>>>>options_.setLanguageIn(LanguageMode.ECMASCRIPT5_STRICT) >>>>> >>>>>in the class JSClosureCompilerWrapper? >>>>> >>>>>The compiler defaults to ECMASCRIPT3 and I guess that might explain >>>>>why it doesn't handle 'newer' features properly? >>>>> >>>>>EdB >>>>> >>>>> >>>>> >>>>>On Sat, Apr 4, 2015 at 5:12 PM, Alex Harui <aha...@adobe.com> wrote: >>>>>> After getting this working for the js-debug version, I’ve come to the >>>>>> conclusion that the Google Closure Compiler cannot handle the >>>>>> defineProperties pattern I proposed. The variable and property >>>>>>renaming, >>>>>> and a few other places, gets totally confused by the code in the >>>>>>object >>>>>> structure, even after I added @this JSDoc annotations. It does not >>>>>> recognize the code in the object structure as belonging to the rest >>>>>>of >>>>>>the >>>>>> code in the class and thus renames everything in the object >>>>>>structure in >>>>>> an incompatible way with the rest of the code in the class that has >>>>>>the >>>>>> classname.prototype pattern. It also reports that code in the >>>>>>structure >>>>>> is accessing properties in the class that it shouldn’t and vice >>>>>>versa. >>>>>> >>>>>> So, I’m mulling over the options. The direction I’m currently >>>>>>thinking >>>>>>of >>>>>> trying is to go back to the get_ and set_ pattern and then name those >>>>>> functions in the object structure. Thus the code would look like the >>>>>>old >>>>>> code, but there’d be an additional defineProperties structure like >>>>>>this: >>>>>> >>>>>> /** >>>>>> * @return {number} The offset to write to or read from. >>>>>> */ >>>>>> org_apache_flex_utils_BinaryData.prototype.get_position = function() >>>>>>{ >>>>>> return this.position_; >>>>>> }; >>>>>> >>>>>> >>>>>> /** >>>>>> * @param {number} value The offset to write to or read from. >>>>>> */ >>>>>> org_apache_flex_utils_BinaryData.prototype.set_position = >>>>>>function(value) { >>>>>> this.position_ = value; >>>>>> }; >>>>>> >>>>>> >>>>>> Object.defineProperties(org_apache_flex_utils_BinaryData.prototype, { >>>>>> 'position': { >>>>>> get: org_apache_flex_utils_BinaryData.prototype.get_position, >>>>>> set: org_apache_flex_utils_BinaryData.prototype.set_position >>>>>> } >>>>>> }); >>>>>> >>>>>> In addition, each property in the structure would have to be >>>>>>‘exposed’ >>>>>>as >>>>>> “not rename-able” probably by doing something like this: >>>>>> >>>>>> >>>>>> /** >>>>>> * @type {number} The offset to write to or read from. >>>>>> */ >>>>>> org_apache_flex_utils_BinaryData.prototype.position; >>>>>> >>>>>> This has the disadvantage of adding more prototype slots at startup, >>>>>>but >>>>>> might make debugging easier. Right now, the call stacks are less >>>>>>helpful >>>>>> because they often contain a function call “set” and you don’t know >>>>>>what >>>>>> setter it is. This new pattern would hopefully result in the >>>>>>debugger >>>>>> showing the function with its set_position name. We’ll see. >>>>>> >>>>>> >>>>>> Another option is to try to get GCC to not rename any variables and >>>>>>absorb >>>>>> the extra code size until they get around to handling this better. >>>>>> >>>>>> Thoughts? I could have certainly missed something about how to get >>>>>>GCC >>>>>>to >>>>>> handle this correctly. >>>>>> >>>>>> -Alex >>>>>> >>>>>> >>>>>> On 3/12/15, 9:15 PM, "Alex Harui" <aha...@adobe.com> wrote: >>>>>> >>>>>>>I’ve been plugging away trying to convert the FlexJS framework to use >>>>>>>Object.defineProperty. >>>>>>> >>>>>>>I’m looking to get other’s thoughts on how to indent, comment and >>>>>>>otherwise format or style the actual code. Here’s what I mean: >>>>>>> >>>>>>>The old code looked like this: >>>>>>> >>>>>>>/** >>>>>>> * @expose >>>>>>> * @return {number} The offset to write to or read from. >>>>>>> */ >>>>>>>org_apache_flex_utils_BinaryData.prototype.get_position = function() >>>>>>>{ >>>>>>> return this.position_; >>>>>>>}; >>>>>>> >>>>>>> >>>>>>>/** >>>>>>> * @expose >>>>>>> * @param {number} value The offset to write to or read from. >>>>>>> */ >>>>>>>org_apache_flex_utils_BinaryData.prototype.set_position = >>>>>>>function(value) >>>>>>>{ >>>>>>> this.position_ = value; >>>>>>>}; >>>>>>> >>>>>>> >>>>>>> >>>>>>>I think the equivalent with Object.defineProperties is this: >>>>>>> >>>>>>>Object.defineProperties(org_apache_flex_utils_BinaryData.prototype, { >>>>>>> 'position': { >>>>>>> get: function() { >>>>>>> return this.position_; >>>>>>> }, >>>>>>> set: function(value) { >>>>>>> this.position_ = value; >>>>>>> } >>>>>>> } >>>>>>> }); >>>>>>> >>>>>>>As you can see, it looks like we are building out object structures >>>>>>>with >>>>>>>functions as values. One of the things I don’t like is it causes the >>>>>>>code >>>>>>>to be indented pretty far in. And when you start placing in >>>>>>>comments, >>>>>>>they are also indented and it really starts to look cluttered. >>>>>>> >>>>>>> >>>>>>>I’m also wondering whether comments even matter for the Google >>>>>>>Closure >>>>>>>Compiler. No code will directly access the get or set properties of >>>>>>>these >>>>>>>subobjects. >>>>>>> >>>>>>>Finally, I’ve been reading that @expose is deprecated in GCC. I’m >>>>>>>wondering how we are supposed to prevent property renaming, if at >>>>>>>all. >>>>>>> >>>>>>> >>>>>>>Thoughts? >>>>>>> >>>>>>>Thanks, >>>>>>>-Alex >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>Ix Multimedia Software >>>>> >>>>>Jan Luykenstraat 27 >>>>>3521 VB Utrecht >>>>> >>>>>T. 06-51952295 >>>>>I. www.ixsoftware.nl >>>> >>> >>> >>> >>> -- >>> Ix Multimedia Software >>> >>> Jan Luykenstraat 27 >>> 3521 VB Utrecht >>> >>> T. 06-51952295 >>> I. www.ixsoftware.nl >>> >>> >>> -- >>> Ix Multimedia Software >>> >>> Jan Luykenstraat 27 >>> 3521 VB Utrecht >>> >>> T. 06-51952295 >>> I. www.ixsoftware.nl >> >> >> >>-- >>Ix Multimedia Software >> >>Jan Luykenstraat 27 >>3521 VB Utrecht >> >>T. 06-51952295 >>I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
