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:function(){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
