flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [FlexJS] DefineProperty Code Style
Date Mon, 06 Apr 2015 12:17:00 GMT
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 <erik@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 <aharui@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" <erik@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 <aharui@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" <aharui@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

Mime
View raw message