Certain Symbols are not Renamed
Chad Killingsworth
/** @constructor */
function MyType() { }
MyType.prototype.zoom= function() { alert("zoom");};
var a = new MyType();
a.zoom();
Produces the following:
function a() { }
a.prototype.zoom = function() { alert("zoom") };
(new a).zoom();
Yet if you change the initial code to:
/** @constructor */
function MyType() { }
MyType.prototype.nonZoom= function() { alert("zoom"); }
var a = new MyType();
a.nonZoom();
You get the following (and more expected) output:
function a() { }
new a;
alert("zoom");
What's going on here? Why did the zoom prototype not get renamed/
inlined?
Chad Killingsworth
John Lenz
Without looking my guess is the standard external define a property zoom.
Chad Killingsworth
extern. I still don't understand why that would be applied to a
generic object that doesn't inherit from CSSProperties.
I'm picking on zoom here because it's the latest thing I've noticed.
I've seen this behavior with various other symbols as well.
Chad Killingsworth
On Jan 30, 10:32 pm, John Lenz <concavel...@gmail.com> wrote:
> Without looking my guess is the standard external define a property zoom.
>
> On Jan 30, 2010 8:21 PM, "Chad Killingsworth" <
>
bolinfest
does not rename properties whose names collide with externs by default
because you could have a function that takes an object and invokes its
zoom method where it is unclear if it is a native object with an
extern'd zoom method or your object with its renameable zoom method.
If you use the compiler programmatically (or subclass
CompilerRunner.java), you can enable additional (more experimental)
passes by setting fields on the CompilerOptions object. In this case,
you want to set disambiguateProperties to true in CompilerOptions:
http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/CompilerOptions.java
to enable the DisambiguateProperties pass:
http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/DisambiguateProperties.java.
The best way to figure out what a compiler pass does is by looking at
its corresponding test:
http://code.google.com/p/closure-compiler/source/browse/trunk/test/com/google/javascript/jscomp/DisambiguatePropertiesTest.java.
As the comment in CompilerOptions states, the goal of
disambiguateProperties is to: "Rename properties to disambiguate
between unrelated fields based on type information." It is also common
to set ambiguateProperties to true when disambiguateProperties is set
to true. Though the two sound like complementary operations, they
aren't. Confusing, I know.
On Jan 31, 8:43 pm, Chad Killingsworth
Chad Killingsworth
extern and it's symbols began behaving the same way.
Applying every extern symbol to every object seems to be overkill.
JSDoc tags should resolve any such ambiguity you mention. The only
argument I can think of to keep it this way would be the gzip
argument.
Looks like I'll be building my own version of the compiler.
This behavior seems to be a prime candidate for a command-line switch
if it is not going to be included in ADVANCED_OPTIMIZATIONS by
default.
Chad Killingsworth
On Jan 31, 8:57 pm, bolinfest <bolinf...@gmail.com> wrote:
> Hi Chad, this is a great question. To be absolutely safe, the Compiler
> does not rename properties whose names collide with externs by default
> because you could have a function that takes an object and invokes its
> zoom method where it is unclear if it is a native object with an
> extern'd zoom method or your object with its renameable zoom method.
> If you use the compiler programmatically (or subclass
> CompilerRunner.java), you can enable additional (more experimental)
> passes by setting fields on the CompilerOptions object. In this case,
> you want to set disambiguateProperties to true in CompilerOptions:http://code.google.com/p/closure-compiler/source/browse/trunk/src/com...
> to enable the DisambiguateProperties pass:http://code.google.com/p/closure-compiler/source/browse/trunk/src/com....
> The best way to figure out what a compiler pass does is by looking at
> its corresponding test:http://code.google.com/p/closure-compiler/source/browse/trunk/test/co....
Nick Santos
<chadkill...@missouristate.edu> wrote:
> Well that's definitely what is going on. I included my google maps
> extern and it's symbols began behaving the same way.
>
> Applying every extern symbol to every object seems to be overkill.
> JSDoc tags should resolve any such ambiguity you mention. The only
> argument I can think of to keep it this way would be the gzip
> argument.
>
> Looks like I'll be building my own version of the compiler.
>
> This behavior seems to be a prime candidate for a command-line switch
> if it is not going to be included in ADVANCED_OPTIMIZATIONS by
> default.
>
> Chad Killingsworth
We're still trying to figure out the best way to roll these
optimizations out. They're relatively new. They still have a couple of
kinks and gotchas. For example, they make debugging a bit harder. And
type violations in the code will lead to these optimizations breaking
things in unexpected ways (though we do make some effort to protect
against this).
I'd be interested in hearing what experiences you have with them, both
good and bad.
Nick
Chad Killingsworth
this particular issue. I'm still tracking through source code to see
if I can figure out where this is coming from.
I didn't see any adverse effects from enabling these passes on my
code. It did remove a method that I had failed to properly export.
That particular method wasn't untouched before.
Chad Killingsworth
Chad Killingsworth
In RenameProperties.java:
http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/RenameProperties.java#300
extern properties are added without regard to namespace or object
type. If I'm reading this correctly, every extern property is assumed
to apply to every object.
I would think that some sort of scoping needs applied here.
Thoughts?
Chad Killingsworth
On Feb 1, 1:13 pm, Chad Killingsworth
Nick Santos
<chadkill...@missouristate.edu> wrote:
> Well I've tracked this further and think this may actually be a bug.
>
> In RenameProperties.java:
> http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/RenameProperties.java#300
> extern properties are added without regard to namespace or object
> type. If I'm reading this correctly, every extern property is assumed
> to apply to every object.
>
> I would think that some sort of scoping needs applied here.
>
> Thoughts?
>
> Chad Killingsworth
By design, RenameProperties does not take type information into
account. DisambiguateProperties and AmbiguateProperties do take type
information into account, and rename properties to something that does
not conflict with an extern when it is possible to do so.
In general, we try to maintain a strict separation between
optimizations that consume type information and optimizations that do
not. (Performing a type-based optimization that works correctly when
type information is incomplete is tricky.)
Nick
Chad Killingsworth
what's preventing it from being renamed.
Chad Killingsworth
On Feb 1, 4:31 pm, Nick Santos <nicksan...@google.com> wrote:
> On Mon, Feb 1, 2010 at 5:21 PM, Chad Killingsworth
>
> <chadkillingswo...@missouristate.edu> wrote:
> > Well I've tracked this further and think this may actually be a bug.
>
> > In RenameProperties.java:
> >http://code.google.com/p/closure-compiler/source/browse/trunk/src/com...
Chad Killingsworth
and re-checked out the source. DisambiguateProperties did the trick
this time.
Thanks for the help.
Chad Killingsworth
On Feb 1, 5:04 pm, Chad Killingsworth