Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: error (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <D1476C23.29D68%aharui@adobe.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>
Date: Mon, 6 Apr 2015 09:25:08 +0200
Message-ID: 
 <CAJs+wW3q8bsgvN53obZzK8o1SG+8so6-U2cY2=1DBs6xzFHqgw@mail.gmail.com>
Subject: [FlexJS] DefineProperty Code Style
From: Erik de Bruin <erik@ixsoftware.nl>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Content-Type: multipart/alternative; boundary=001a113f2af69f93fa0513093230

--001a113f2af69f93fa0513093230
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <javascript:;>=
>
wrote:
> Thanks for the suggestion.  It didn=E2=80=99t seem to help.  I=E2=80=99ve=
 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 definePr=
operties
> functions to be referencing other functions in the class and vice versa.
>
> For example, this method references productService which is defined in th=
e
> 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 so=
mething 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 w=
ay 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 smar=
t
> about use of string literals as a hint as to what can=E2=80=99t be rename=
d, 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 usag=
e 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 <javascript:;>>
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
<javascript:;>> 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 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 i=
n
>>> 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 structur=
e
>>> is accessing properties in the class that it shouldn=E2=80=99t and vice=
 versa.
>>>
>>> So, I=E2=80=99m mulling over the options.  The direction I=E2=80=99m cu=
rrently 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 l=
ike 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=98e=
xposed=E2=80=99
>>>as
>>> =E2=80=9Cnot rename-able=E2=80=9D 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, bu=
t
>>> 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 yo=
u 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 GCC
>>>to
>>> handle this correctly.
>>>
>>> -Alex
>>>
>>>
>>> On 3/12/15, 9:15 PM, "Alex Harui" <aharui@adobe.com <javascript:;>>
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, c=
omment 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 wit=
h
>>>>functions as values.  One of the things I don=E2=80=99t like is it caus=
es 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


--=20
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

--001a113f2af69f93fa0513093230--