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
>
>
