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
