This is very strange. It could be that certain words like position and
data are in a blacklist. I tried this (essentially the same example but
using productService as the name)
// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// @output_file_name default.js
// @language ECMASCRIPT5_STRICT
// ==/ClosureCompiler==
// ADD YOUR CODE HERE
goog.provide('org_apache_flex_utils_BinaryData');
/**
* @constructor
*/
var org_apache_flex_utils_BinaryData = function () {
/**
* @private
* @type {number}
*/
this.productService_;
this.someFunction();
}
/**
* @private
*/
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;
}
}
});
And got this:
'use
strict';Object.defineProperties(function(){console.log(this.b)}.prototype,{
productService:{get:function(){return this.a},set:function(a){this.a=a}}});
Along with a warning:
JSC_INEXISTENT_PROPERTY: Property productService never defined on
org_apache_flex_utils_BinaryData. Did you mean productService_? at line 24
character 21
console.log(this.productService);
As you can see, in the console.log() call, this.productService has been
renamed to this.b. That is essentially what is screwing up the JS release
version.
Or did I make a mistake somewhere?
Thanks,
-Alex
On 4/6/15, 7:07 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>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#exter
>>>>ns
>>>>
>>>> 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
