Imposing types

[John Leidegren]

Why is it that the compiler doesn't treat this situation better?

/**
* @constructor
*/
function b() {
this.transform = [];
this.thing = document.createElement("DIV");
}

f(new b().transform, new b().thing);

// using the following extern source
function a() {};
a.prototype.thing;

How come neither transform nor thing is renamed here? By the looks of
it, the return type of the constructor function is "b", this type is
unrelated to both a, and where ever transform is defined. Why then
does the compiler feel that it's necessary to keep these names? (even
if I wish it wouldn't)

And also, why doesn't this work?

/** @param {Object.<string, *>} data */
function f(data) {
data.SomeProperty
}

In much the same way data["SomeProperty"] would. I think having to
quote all things public/static makes the code a bit too verbose, I
rather not have to do that everywhere and I think it cuts into the
readability.

The "All Unquoted" rule is easy to understand but there should really
be a "All Unquoted +/- Annotations" rule that would rename stuff based
on type information too, or not rename stuff based on a type
expression like "Object.<string, *>"

I've been using the REST API, and read that there are more options
available to the client, is there any such options, as of date, that
would accomplish what I want?

[John Lenz]

It exists, it just can't be turned on by default:

http://code.google.com/p/closure-compiler/wiki/ExperimentalTypeBasedPropertyRenaming

Think of it as "super advanced mode".

[John Lenz]

oh, and Object.<String, *> doesn't tell you anything about a value be internal or external, you still need a renaming rule.

[John Leidegren]

Using my imagination I kind of hoped that it would, as the compiler
doesn't rename strings... Now, the object names aren't strings per se,
but I told the compiler that the keys in this object are strings
(static).

Then again, it's question where this is an internal or external
reference, and I guess that makes more sense, even though I was hoping
that the type annotation would accomplish the same thing here.

But the question remains then, how do I best handle "dynamic data"
then?

What I'm dealing with here is a JSON response, coming of the server.
I'd like to refrain from having to quote and wrap access in brackets.
like "this["SomeProperty"]" because authoring the scripts, that's
quickly going to become somewhat of a pain (I think it's a bit too
verbose).

I've been contemplating just, not compiling these scripts to steer
away from the problem entirely but I was really hoping that it would
be a nice in between, where I could leverage some of the type system
imposed by the closure compiler without sacrificing the dynamic
aspect, kind a like an opt-in/opt-out situation.

Like this, dude /** @param {data} data */ dynamic data object, don't
touch, you don't understand what this is and you'll break my code if
you start renaming things.

The compiler could do something like this:

var a = data.reallyLongAndAnnoyingDataSlot...
// now "a" can be used as a synonym if the property is used in a lot
of places

That imposes some restrictions on what a data object can be (read-only
JSON in this case), and how you may use it, but I really like it in
principle. Now I understand that there's nothing like this in the
compiler today, as I'm asking for something very specific to tailor to
my own needs but how would you handle these situation today? Surely
the quote and brackets approach can't be all there is...

One last thing, is "Super Advanced Mode" stable? or might I end up
with a result that's broken because these feature is incomplete in
some way?

On Oct 20, 3:44 am, John Lenz <concavel...@gmail.com> wrote:
> oh, and Object.<String, *> doesn't tell you anything about a value be
> internal or external, you still need a renaming rule.
>
>
>
>
>
>
>
> On Wed, Oct 19, 2011 at 6:38 PM, John Lenz <concavel...@gmail.com> wrote:
> > It exists, it just can't be turned on by default:
>

> >http://code.google.com/p/closure-compiler/wiki/ExperimentalTypeBasedP...

>
> > Think of it as "super advanced mode".
>

> > On Wed, Oct 19, 2011 at 10:55 AM, John Leidegren <john.leideg...@gmail.com

[John Leidegren]

Sorry, feels as if I'm asking a lot, but how do I enable
ExperimentalTypeBasedPropertyRenaming?

On Oct 20, 3:38 am, John Lenz <concavel...@gmail.com> wrote:
> It exists, it just can't be turned on by default:
>

> http://code.google.com/p/closure-compiler/wiki/ExperimentalTypeBasedP...

>
> Think of it as "super advanced mode".
>
> On Wed, Oct 19, 2011 at 10:55 AM, John Leidegren

> <john.leideg...@gmail.com>wrote:

[Chris Price]

I think Jon's referring to the following -

http://closuretools.blogspot.com/2011/01/property-by-any-other-name-part-3.html

"Using Type Analysis for Better Renaming"

[John Lenz]

On Wed, Oct 19, 2011 at 11:33 PM, John Leidegren <john.le...@gmail.com> wrote:

Using my imagination I kind of hoped that it would, as the compiler
doesn't rename strings... Now, the object names aren't strings per se,
but I told the compiler that the keys in this object are strings
(static).

Then again, it's question where this is an internal or external
reference, and I guess that makes more sense, even though I was hoping
that the type annotation would accomplish the same thing here.

But the question remains then, how do I best handle "dynamic data"
then?

What I'm dealing with here is a JSON response, coming of the server.
I'd like to refrain from having to quote and wrap access in brackets.
like "this["SomeProperty"]" because authoring the scripts, that's
quickly going to become somewhat of a pain (I think it's a bit too
verbose).

You get used to it. :-) 

 

I've been contemplating just, not compiling these scripts to steer
away from the problem entirely but I was really hoping that it would
be a nice in between, where I could leverage some of the type system
imposed by the closure compiler without sacrificing the dynamic
aspect, kind a like an opt-in/opt-out situation.

Your choices are:

1) don't use advanced mode (use simple)

2) define the json structure in the externs file for your project

3) use quoted property names

 

Like this, dude /** @param {data} data */ dynamic data object, don't
touch, you don't understand what this is and you'll break my code if
you start renaming things.

This relies on perfect type information  

The compiler could do something like this:

var a = data.reallyLongAndAnnoyingDataSlot...
// now "a" can be used as a synonym if the property is used in a lot
of places

That imposes some restrictions on what a data object can be (read-only
JSON in this case), and how you may use it, but I really like it in
principle. Now I understand that there's nothing like this in the
compiler today, as I'm asking for something very specific to tailor to
my own needs but how would you handle these situation today? Surely
the quote and brackets approach can't be all there is...

It is all that is needed.

 

One last thing, is "Super Advanced Mode" stable? or might I end up
with a result that's broken because these feature is incomplete in
some way?

It is used internally at Google by some large projects 

[John Lenz]

You need to use the Java interface. http://blog.bolinfest.com/2009/11/calling-closure-compiler-from-java.html

Closure Compiler's Java API has two options: disambiguateProperties and ambiguateProperties.  You would typically both enable both.

[Johannes Nel]

quick kick back on calling it from java, what kind of performance
boost can i expect if i don't jit the jar the whole time (basically
write a java wrapper using jetty or so) i assume people have done
this.

--
j:pn
\\no comment

[John Lenz]

Plovr is a development server that can be use to keep the compiler "hot":  http://plovr.com/

You can give it a try.

[John Leidegren]

I see, I thought the Java API was the same as using the compiler from
the command line, I see know what you mean. Thanks! That's actually
gonna make something easier to manage.

John

On Oct 20, 7:45 pm, John Lenz <concavel...@gmail.com> wrote:
> You need to use the Java interface.http://blog.bolinfest.com/2009/11/calling-closure-compiler-from-java....

>
> Closure Compiler's Java API has two options: disambiguateProperties and
> ambiguateProperties.  You would typically both enable both.
>
> On Thu, Oct 20, 2011 at 12:29 AM, John Leidegren

> <john.leideg...@gmail.com>wrote:

[John Leidegren]

Thanks again!

FYI, https://github.com/leidegre/vjscomp

Works really well! Eventually I'm gonna look into more advanced
options but I find the use of quoted property names to actually be
simpler than anything else.

John

On Oct 20, 7:45 pm, John Lenz <concavel...@gmail.com> wrote:

> You need to use the Java interface.http://blog.bolinfest.com/2009/11/calling-closure-compiler-from-java....

>
> Closure Compiler's Java API has two options: disambiguateProperties and
> ambiguateProperties.  You would typically both enable both.
>
> On Thu, Oct 20, 2011 at 12:29 AM, John Leidegren

> <john.leideg...@gmail.com>wrote:

[Tim Wintle]

On Thu, 2011-10-20 at 10:39 -0700, John Lenz wrote:
> 2) define the json structure in the externs file for your project

FWIW, I've grown to like this option - it enforces a nice place for the
JSON API to be defined and documented between the back and fontends.

I only wish that third party APIs (especially Google ones) would expose
more externs for their json structures / javascript APIs. I'm certain
they exist already, but they're not separated and made publicly
available.

Tim