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
