Permalink
Browse files

function.bind

  • Loading branch information...
1 parent 8aea657 commit 76f92dbe83b927ef17198d349596c09737aa3e12 @douglascrockford committed Feb 14, 2012
Showing with 7 additions and 2 deletions.
  1. +7 −2 jslint.js
View
@@ -1,5 +1,5 @@
// jslint.js
-// 2012-02-13
+// 2012-02-14
// Copyright (c) 2002 Douglas Crockford (www.JSLint.com)
@@ -4082,6 +4082,11 @@ klass: do {
case '}':
case ':':
break;
+ case '.':
+ if (peek().string !== 'bind' || peek(1).id !== '(') {
+ warn('unexpected_a');
+ }
+ break;
default:
stop('unexpected_a');
}
@@ -6382,7 +6387,7 @@ klass: do {
};
itself.jslint = itself;
- itself.edition = '2012-02-13';
+ itself.edition = '2012-02-14';
return itself;
}());

9 comments on commit 76f92db

hco replied Apr 16, 2012

Hi,

would you accept a pull request that makes the list of accepted functions or the whole check (as introduced in 8aea657) configurable?

Greetings,
Christian

Why?

hco replied Apr 16, 2012

Well, we are using a "framework", which provides helpers around bind.
In the (deprecated)version of the framework, these helpers are added to the function prototype, and it's common sense to call them in a way that these checks forbid.

I understand that it would be a best practice to avoid this behavior,
changing this throughout our whole application is not an option right now, and I don't want to remove jslint from our CI.

I guess we're not the only ones encountering this issue, and making it configurable would solve it in a (imho) sane way.

This seems like a bad practice, don't you think?

hco replied Apr 16, 2012

Yep, I kinda agree.
And I agree that this check should exist.

But as mentioned before, at the moment it's no option to "fix" this within our code base immediately.

If we could disable this check, we would be able to run JSLint in our CI. As long as I can't disable the check, I can't tell my developers that our build has to be stable always, because JSLint would always break the build.

So, IMHO it would be worse for us (and probably others) to abandon the usage of JSLint instead of deactivating this check.

Do you see any harm in making these things configurable?
Those who disable such a check should be aware of what they are doing.

It would encourage a bad practice.

hco replied Apr 16, 2012

Most things you can configure in JSLint encourage a bad practice.

Making them configurable is a compromise.

They were existing bad practices, to ease transition. You are promoting a new bad practice.

hco replied Apr 16, 2012

We're talking about easing transition here, too.

I disagree, but I think i won't be able to convince you.
I was thinking that you wouldn't accept that pull request in the first place. That's why I asked before writing it. Thanks for considering it.

Please sign in to comment.