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
