Jason,
maybe I have attributed to Dave something that was actually said by
DBJ ... sorry in that case.
I am just against inclusion in core and against the inclusion of any
mechanism for that scope in general.
As said, if the tool is an external and independent "Lint-like"
solution I don't see any problem. I already use tools like those
myself (jsl).
Two different versions of jQuery will just create more confusion and
more maintenance problems.
Diego
On 15 Gen, 20:11, Jason Persampieri <papp...@gmail.com> wrote:
> 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.
