jQuery 1.4.2

[Chad Killingsworth]

I'm in need of an extern file for jQuery 1.4.2. Before I spend my own
time writing one, is there one floating around somewhere?

If not, I'll try to get one written and submitted.

Chad Killingsworth

[Alan Leung]

I am not sure.

Although I wonder if we can hack up 

http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/ExternExportsPass.java

to do this for us.

-Alan

[Nathan Naze]

Can't you just include uncompressed jQuery 1.4.2 into the compiler
input rather than keeping it as an extern?

Nathan

[Chad Killingsworth]

Don't I wish, but no - not last time I tried. The way jQuery is
written isn't really compatible with advanced mode of the compiler.

Chad Killingsworth

On Aug 13, 6:29 pm, Nathan Naze <nn...@google.com> wrote:
> Can't you just include uncompressed jQuery 1.4.2 into the compiler
> input rather than keeping it as an extern?
>
> Nathan
>
>
>
> On Fri, Aug 13, 2010 at 4:28 PM, Alan Leung <acle...@gmail.com> wrote:
> > I am not sure.
> > Although I wonder if we can hack up

> >http://code.google.com/p/closure-compiler/source/browse/trunk/src/com...

[Chad Killingsworth]

It's an interesting idea.

Chad

On Aug 13, 6:28 pm, Alan Leung <acle...@gmail.com> wrote:
> I am not sure.
>
> Although I wonder if we can hack up
>

> http://code.google.com/p/closure-compiler/source/browse/trunk/src/com...

>
> to do this for us.
>
> -Alan

> <http://code.google.com/p/closure-compiler/source/browse/trunk/src/com...>

[Wesley Walser]

I think the jQuery team is using closure as the minification tool in their build process. Someone active on that team would likely be interested in helping out if they haven't already done the work themselves.

Wes

[Chad Killingsworth]

They are, but I don't think they are using advanced optimizations.
I'll check in with them first though.

Chad Killingsworth

[Matt]

The way we've been handling this is using the jQuery 1.3 extern file
that is already out there. As soon as we hit a function that isn't in
the externs we just add it. We haven't had to add too many things
(and actually have found a few functions that were not in the 1.3 file
that should have been).

On Aug 13, 7:17 pm, Chad Killingsworth

[Eric Siroker]

I used:
http://www.dotnetwise.com/Code/Externs

With these inputs:
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js
jQuery

Seemed to do the job.

Eric

[Chad Killingsworth]

I've got most of the work for a 1.4.2 extern file done - I should
finish it in the next couple of weeks. I'm auto generating the file
from the jQuery documentation.

Chad Killingsworth

[Alan Leung]

Nice, thanks again!

[Chad Killingsworth]

Ready for testing: http://code.google.com/p/closure-compiler/issues/detail?id=260

Chad Killingsworth

[Eric Siroker]

On Mon, Oct 4, 2010 at 12:30 PM, Chad Killingsworth
<chadkill...@missouristate.edu> wrote:
> Ready for testing: http://code.google.com/p/closure-compiler/issues/detail?id=260

Nice work, Chad. I'm glad you decided to write a program to generate
the externs file from jQuery's documentation rather than to write the
externs manually. The type annotations help a great deal. We've
already uncovered a few misuses of jQuery in our codebase. And I'm
sure future misuse will be much harder now that we have a
type-annotated externs file.

That said, a few things are missing:

.attr(arg1, arg2)
http://api.jquery.com/attr/
(One argument overload works, two doesn't.)

.css(arg1, arg2)
http://api.jquery.com/css/
(One argument overload works, two doesn't.)

.html()
http://api.jquery.com/html/
(Should always return just {string} not {(string|jQuery.jQueryObject)}
if I'm not mistaken.)

$(window)
http://api.jquery.com/jQuery/

$("<div/>", { "class": "test" })
http://api.jquery.com/jQuery/#jQuery2

.unbind()
http://api.jquery.com/unbind/
(Zero argument overload isn't listed in the explicit overloads, but is
mentioned in the description.)

Suggestion: Rename type jQuery.jQueryObject to something shorter, like
just jQueryObject. It's a bit of pain to type it out completely when
I'm writing type annotations for code that interacts with jQuery. It
sure beats having to use plain {Object} though :)

You mentioned you'd post your generator program once all the kinks are
worked out. I'd recommend just releasing it now. Instead of us
complaining about things that aren't supported, we can contribute
patches which add the correct support.

Eric

[Eric Siroker]

On Fri, Oct 8, 2010 at 5:11 PM, Eric Siroker <esir...@gmail.com> wrote:
> .html()
> http://api.jquery.com/html/
> (Should always return just {string} not {(string|jQuery.jQueryObject)}
> if I'm not mistaken.)

Whoops, I was mistaken. .html() with a parameter returns the original
jQuery object. It's a shame we can't specify return types based on
what parameters were received because, unless coaxed, any type-checked
code that relies on the return value of .html() complains that it
might potentially be receiving a jQuery.jQueryObject.

Eric

[Chad Killingsworth]

I'll get these items adjusted this week. I'm just getting back from a
conference.

On the jQuery.jQueryObject - I did it that way to avoid global
namespace conflicts, but it is longer to type. I can switch it pretty
easy.

In addition to what you have listed, I've found a few things myself.
I'd also like to go through and apply @nosideeffect annotations to the
few methods where it applies. That will probably have to be a manual
list.

And I completely agree on setting return types based on parameters -
if only that were an option. However this is the only extern I've
worked with where that issue came up so it probably isn't worth the
time to augment the compiler to support that.

Chad Killingsworth

On Oct 8, 8:08 pm, Eric Siroker <esiro...@gmail.com> wrote:

[Chad Killingsworth]

I've uploaded a new version which should address all of these issues.

Chad Killingsworth

On Oct 14, 11:11 am, Chad Killingsworth

[Chad Killingsworth]

Noticed I missed the unbind comment:

The Xml for the documentation (http://api.jquery.com/api/) doesn't
contain any signatures with no parameters or where all parameters are
optional. Looks like the jQuery documentation will need changed to fix
that one.

Chad Killingsworth

On Oct 18, 2:34 pm, Chad Killingsworth

[Eric Siroker]

Thanks for the update, Chad. Suggestions for version published on Mon
Oct 18 14:02:11 2010:

-Add {string|number} to arg2 of attr()
-Add {number} to arg1 of .val()
-unbind()

You would prefer to wait for jQuery's docs to be updated instead of
tweaking the generated externs file?

Eric

[Chad Killingsworth]

> You would prefer to wait for jQuery's docs to be updated instead of
> tweaking the generated externs file?

That would definitely be preferable. To date, I'm not doing a single
hand edit to the generated file. If we want to be done for now auto-
generating the file, we can hand edit it to death during code review.

On attr, the "value" parameter has a type of Object. Looks to me like
this should be string (or string,number).
On val, the "value" parameter has a type of String. However the
description says string or array of strings (number isn't even
listed).
On unbind, it really needs a new signature that takes no parameters.

Chad Killingsworth

[Nianwei Liu]

Chad,
What about 1.4.3 and the fresh off the oven jquery mobile? :)

On Oct 19, 8:51 am, Chad Killingsworth

[Chad Killingsworth]

Already done.

Chad Killingsworth

[Nianwei Liu]

Great! Will check it out. Thanks.

[Chad Killingsworth]

Ok so the already done was jQuery 1.4.3. For jQuery mobile, I'll need
to see if they have an xml feed of the api as a source.

Chad Killingsworth

[Chad Killingsworth]

I've posted the extern generator I wrote (including source code) at
http://blogs.missouristate.edu/web/2010/11/02/jquery-extern-generator-for-closure-compiler/

Chad Killingsworth

On Oct 24, 7:23 am, Chad Killingsworth

[bigo]

is there no way to do something like overloads in extern definitions -
to specify that the return type differs based on the arguments?
eg/ .text is externed as such:
/**
* @param {(string|function(number,string))=} arg1
* @return {(string|jQueryObject)}
*/
jQueryObject.prototype.text = function(arg1) {};


but this code:
$("#foo").text($("bar").text())

throws an exception if you jack up the warnings:
JSC_TYPE_MISMATCH. actual parameter 1 of jQueryObject.prototype.text
does not match formal parameter
found : (jQueryObject|null|string)
required: (function (number, string): ?|string|undefined) at
<whatever>

this should work since .text() without arguments always returns a
string, but it fails because jQueryObject is in the possible return
values of .text() but not in the possible arguments. apologies if
this has been discussed already.

-o

On Nov 2, 1:30 pm, Chad Killingsworth
<chadkillingswo...@missouristate.edu> wrote:
> I've posted the extern generator I wrote (including source code) athttp://blogs.missouristate.edu/web/2010/11/02/jquery-extern-generator...

[Chad Killingsworth]

No this isn't possible - and it was discussed earlier in the thread.
It would be nice to do something like this, but in practice this is
the only extern I've worked with where functions returned different
types based on the number of parameters.

You have to typecast your return values. See the comment at the top of
the extern file.

Chad Killingsworth

[John Lenz]

It is usually best to wrap these types of issues in a simple function and let the compiler inline it (so the is no runtime overhead).

sent from a mobile phone excuse the spelling ...

[bigo]

(sorry - i had actually skimmed the earlier post but didn't grok that
it was referring to the same issue)

i'm going ahead with the technique of making small wrapper functions,
but i wonder if this is something to open as an actual issue with the
Compiler team. while I agree that maybe the drastically different
behavior doesn't need to be supported (getters/setters with the same
name), there are also multiple signatures for the setter portion of
these functions that might be in wider use. eg/ for jQuery's .attr,
you can pass either (Object.<string, Object>), or (string, Object), or
(string, function()). even if you were viewing this function as only
a setter, there'd be no way to enforce a truly correct invocation
since .attr("bar") is still valid under the jsdoc signature you'd
generate here.

it seems like as long as Compiler is going to add type safety to a
loosely typed language, it may as well go all the way and support
method overloading gracefully. not that i necessarily support what
jQuery has done here.

thoughts before i dive into the code / take it up as an Issue?



On Nov 4, 4:52 am, Chad Killingsworth

[John Lenz]

You are welcome to file an issue, but I don't think anything will happen with it within Google.  This seems like a slippery slope, there is no reason to think that overloading is limited to types, you could do the same with values:

  foo(1) // returns string

  foo(2) // returns number

etc, I don't see the type system ever supporting overloading based on values.

[Jeoff Wilks]

It's reasonable to say that you must be able to determine the output type from the input type. That's the precedent of statically typed languages.

[Chad Killingsworth]

I posted and had corrected 2 of the above issues on the jQuery
documentation. attr and unbind are now correctly annotated. With val,
the jQuery folks wanted to keep it a string. They said a number would
simply be converted to a string here. The description for val
specifically says it takes a string as well.

http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.4.4.externs.js

Chad Killingsworth

[John Lenz]

This basically forces annoying conversions like "x.toString()" in advanced mode (to avoid type warnings) if 'number' is actually valid for the method.

[Chad Killingsworth]

Number works just fine. I'm thinking of coding an exception into my
extern program because it is highly annoying.

Chad Killingsworth

On Nov 16, 8:07 pm, John Lenz <concavel...@gmail.com> wrote:
> This basically forces annoying conversions like "x.toString()" in advanced
> mode (to avoid type warnings) if 'number' is actually valid for the method.
>
> On Tue, Nov 16, 2010 at 4:14 AM, Chad Killingsworth <
>

> chadkillingswo...@missouristate.edu> wrote:
> > I posted and had corrected 2 of the above issues on the jQuery
> > documentation. attr and unbind are now correctly annotated. With val,
> > the jQuery folks wanted to keep it a string. They said a number would
> > simply be converted to a string here. The description for val
> > specifically says it takes a string as well.
>

> >http://code.google.com/p/closure-compiler/source/browse/trunk/contrib...