Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAJs+wW3q8bsgvN53obZzK8o1SG+8so6-U2cY2=1DBs6xzFHqgw@mail.gmail.com>
References: <D1279D1B.27F34%aharui@adobe.com>
 <D144CE40.29ACF%aharui@adobe.com>
 <CAJs+wW2CcPCEW84D7Yr5o4eG=g5hKLye6TGW+Z15xn__UFkCig@mail.gmail.com>
 <D1476C23.29D68%aharui@adobe.com>
 <CAJs+wW3q8bsgvN53obZzK8o1SG+8so6-U2cY2=1DBs6xzFHqgw@mail.gmail.com>
From: Erik de Bruin <erik@ixsoftware.nl>
Date: Mon, 6 Apr 2015 14:17:00 +0200
Message-ID: 
 <CAJs+wW22SjTaJ8jqDKRWyDb9dZK-8VXhhw1JTeo6tJGa5b-7jw@mail.gmail.com>
Subject: Re: [FlexJS] DefineProperty Code Style
To: "dev@flex.apache.org" <dev@flex.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alex,

I used 'http://closure-compiler.appspot.com/' with this input:

// =3D=3DClosureCompiler=3D=3D
// @compilation_level ADVANCED_OPTIMIZATIONS
// @warning_level VERBOSE
// @language ECMASCRIPT5_STRICT
// =3D=3D/ClosureCompiler=3D=3D

'use strict';

/**
 * @constructor
 */
var org_apache_flex_utils_BinaryData =3D function () {}

/**
 * @private
 * @type {number}
 */
org_apache_flex_utils_BinaryData.prototype.position_ =3D 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_ =3D value + 10;
    }
  }
});

var binaryData =3D new org_apache_flex_utils_BinaryData();
binaryData.position =3D 100;
console.log(binaryData.position);

And I got this output (no errors, no warnings):

'use strict';function
a(){}a.prototype.a=3D0;Object.defineProperties(a.prototype,{position:{get:f=
unction(){return
this.a},set:function(c){this.a=3Dc+10}}});var b=3Dnew
a;b.position=3D100;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 l=
ook
> 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=E2=80=99t seem to help.  I=E2=80=99v=
e grepped the GCC
>> code and didn=E2=80=99t see any attempt to handle defineProp.
>>
>> I think the issue is that GCC doesn=E2=80=99t expect code in the defineP=
roperties
>> functions to be referencing other functions in the class and vice versa.
>>
>> For example, this method references productService which is defined in t=
he
>> Object.defineProperties:
>>
>> /**
>>  * @private
>>  */
>> FlexJSStore.prototype.startService =3D function() {
>>   this.productService.send();
>> };
>>
>> Object.defineProperties(FlexJSStore.prototype, {
>>   'productService': {
>>
>> The optimizer renames =E2=80=9Cthis.productServices.send()=E2=80=9D to s=
omething like
>> =E2=80=9Cthis.Jj.send()=E2=80=9D.  It doesn=E2=80=99t seem to know about=
 the defineProperties
>> structure and that there is a non-renamable property called
>> =E2=80=98productService=E2=80=99 so it uses a renaming variable like =E2=
=80=9CJj=E2=80=9D.
>>
>>
>> Putting all of the functions on the prototype slots would allow the
>> optimizer to rename everything together.  But we=E2=80=99d still need a =
way to
>> teach GCC that the properties in the defineProperties structure can=E2=
=80=99t be
>> renamed.  GCC has deprecated @expose.  It appears to be trying to be sma=
rt
>> about use of string literals as a hint as to what can=E2=80=99t be renam=
ed, but it
>> isn=E2=80=99t very cautious.  Use of =E2=80=98productService=E2=80=99 in=
 the MXML output array
>> won=E2=80=99t prevent renaming.  It probably has to be a more direct usa=
ge 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=E2=80=99ve 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 objec=
t
>>>> 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 th=
e
>>>> classname.prototype pattern.  It also reports that code in the structu=
re
>>>> is accessing properties in the class that it shouldn=E2=80=99t and vic=
e versa.
>>>>
>>>> So, I=E2=80=99m mulling over the options.  The direction I=E2=80=99m c=
urrently 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=E2=80=99d 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 =3D function()=
 {
>>>>   return this.position_;
>>>> };
>>>>
>>>>
>>>> /**
>>>> * @param {number} value The offset to write to or read from.
>>>> */
>>>> org_apache_flex_utils_BinaryData.prototype.set_position =3D
>>>>function(value) {
>>>>   this.position_ =3D 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 =E2=80=98=
exposed=E2=80=99
>>>>as
>>>> =E2=80=9Cnot rename-able=E2=80=9D probably by doing something like thi=
s:
>>>>
>>>>
>>>> /**
>>>> * @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, b=
ut
>>>> might make debugging easier.  Right now, the call stacks are less
>>>>helpful
>>>> because they often contain a function call =E2=80=9Cset=E2=80=9D and y=
ou don=E2=80=99t know what
>>>> setter it is.  This new pattern would hopefully result in the debugger
>>>> showing the function with its set_position name.  We=E2=80=99ll 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 GC=
C
>>>>to
>>>> handle this correctly.
>>>>
>>>> -Alex
>>>>
>>>>
>>>> On 3/12/15, 9:15 PM, "Alex Harui" <aharui@adobe.com> wrote:
>>>>
>>>>>I=E2=80=99ve been plugging away trying to convert the FlexJS framework=
 to use
>>>>>Object.defineProperty.
>>>>>
>>>>>I=E2=80=99m looking to get other=E2=80=99s thoughts on how to indent, =
comment and
>>>>>otherwise format or style the actual code.  Here=E2=80=99s 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 =3D function()=
 {
>>>>>  return this.position_;
>>>>>};
>>>>>
>>>>>
>>>>>/**
>>>>> * @expose
>>>>> * @param {number} value The offset to write to or read from.
>>>>> */
>>>>>org_apache_flex_utils_BinaryData.prototype.set_position =3D
>>>>>function(value)
>>>>>{
>>>>>  this.position_ =3D 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_ =3D value;
>>>>>        }
>>>>>    }
>>>>>       });
>>>>>
>>>>>As you can see, it looks like we are building out object structures wi=
th
>>>>>functions as values.  One of the things I don=E2=80=99t like is it cau=
ses 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=E2=80=99m 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=E2=80=99ve been reading that @expose is deprecated in GCC. =
 I=E2=80=99m
>>>>>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


--=20
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl