Diego,
I think you're still not quite understanding what Dave is suggesting.
He is *not* saying everyone running jQuery would be subjected to these
checks.
He *is* saying there is a completely new build of jQuery (let's call
it jQuery-1.4.lint.js) that a developer could *choose* to run against
just to test out their code. And in the documentation, it could be
strongly urged that new developers try this at least once.
Heck, let's take it a step farther... how about jquery-1.4.newb.js
that has some sort of 'tutorial' built in when it sees bad practices?
At least that's how I've interpreted it :)
_jason
On Jan 15, 11:02 am, Diego Perini <diego.per...@gmail.com> wrote:
> Dave,
> I completely agree with Andrea Raimondi above and everything he said
> make sense to me.
>
> Why should we inflict these no sense conditionals onto everybody.
> Should we then check every parameter of every method too, just to be
> helpful to one people not remembering signatures or lazy to lookup a
> documentation page ?
>
> Not useful, none of those checks should be in core, if necessary, for
> DBJ and people needing that, an external checker will be ok, I would
> not like to be the one writing that though :-) Those writing $('*')
> should be returned what they asked, it is "incorrect" to assume
> everybody is a beginner and "time wasting" trying to guess what they
> would do with those selectors.
>
> Diego
>
> On 15 Gen, 18:31, Dave Methvin <dave.meth...@gmail.com> wrote:
>
> > > "Not technically demanding" uh?
> > > I beg to differ on this one.
>
> > Conceptually it's a simple idea: Inspect the parameters being passed
> > to jQuery and its methods, then see if they match the API signature
> > and follow good practice. I started on it years ago but punted (hides
> > head in shame) because it was a lot of work, especially at that time
> > when the jQuery API was changing
> > quickly:http://markmail.org/message/wzkosk2s5jklpkv4
>
> > > First of all, what would the criteria be?
>
> > Whatever the author thought was bad practice or a possible mistake. If
> > you've ever used the original jslint (http://www.jslint.com/) or the
> > (imo) better javascriptlint (http://www.javascriptlint.com/), you know
> > that lint occasionally complains about things that are not outright
> > errors but sometimes indicate problems or are just bad style. The $
> > ("*") case that dbj mentioned is a good one. It's not an error but it
> > is generally not good to do something to every element on the page. I
> > also would flag the case of $("myid") versus the intended $("#myid")
> > on non-xml docs if the selector didn't return any elements--that's a
> > mistake I make a few times a month.
>
> > > pretty much all of the JQuery classes and functions can use
> > > server side tags and code.
>
> > I think dbj was proposing runtime analysis, not static analysis as
> > used with tools like jslint. By the time the jQuery code is called,
> > any server-side tags and code is irrelevant for the kind of checks
> > you'd want to do.
>
> > > The library has *no* knowledge(and rightfully so, imho) of what tags
> > > and/or selectors will be used.
>
> > True, so the messages it gives aren't going to be 100% correct in all
> > cases. That's okay, the developer needs to look at the messages and
> > decide whether it's found a problem or not. The volume of messages
> > could be controllable via options. See the lints above for examples of
> > how to do it.
>
> > > This would slow things down *A LOT* with many checks.
>
> > Performance could definitely be an issue; if the page gets 10 times
> > slower with jquery-lint, people aren't likely to use it regularly for
> > day-to-day development. But even if it *was* 10 times slower, it could
> > still be useful because when people come to a forum complaining their
> > code doesn't work we could point them to jquery-lint.js and tell them
> > to look for problems using that first.
>
> > > Fourth: plug-ins would have to do the same checks.
>
> > A plugin author could certainly write a linted version of their own
> > code, but if they include jquery-lint.js in the page the plugin will
> > automatically get the lint features for any jQuery methods it calls.
>
> > > Fifth: *ANYONE* using improper selectors or using JQuery improperly
> > > deserves his/her fate. Reading the docs is the first thing you should do.
>
> > It's easy to make mistakes, even if the docs are good and you read
> > them well. As I said in that old thread, "I would be embarrassed to
> > tell you how many times I've said $("myid") when I meant $("#myid")
> > and spent 10 minutes trying to figure out what was broken." A lint
> > tool helps find those mistakes, and people can learn things by reading
> > its advice which is always a good thing. It's like a code review in a
> > Javascript file.
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
