Thanks for the PR!

• Contributor signed CLA now or in the past
  • If you just signed, leave a comment here with your real name
• PR's commit messages follow the commit message format

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

CLA signed previously as Caitlin Potter

@caitp - Is this change really necessary? I mean if you really want to test for equality you can do

!!isElement(e) === someBooleanValue

But I would expect that the vast majority of the time you would be doing

isElement(e) == someBooleanValue

Especially if you know that someBooleanValue really is definitely a boolean.

@petebacondarwin I tend to agree, it's really just for @gabejohnson and others who want to use the isEqual() / similar strict matchers. You'd have to ask them how big of a deal it is to use strict matchers for boolean-ish expressions.

Js non-strict equality is a unpopular practice, because it tends to lie.
The rules surrounding truthiness and falsiness are trivia that's easy to
avoid by using strict equality for the average developer, and the type
coercion rules enfoced by == are the source of lots of small, subtle bugs
in production systems. Keeping Booleans Boolean simplifies matters. There
are settings in jshint to support this option.
On Nov 9, 2013 5:47 PM, "Pete Bacon Darwin" notifications@github.com
wrote:

@caitp https://github.com/caitp - Is this change really necessary? I
mean if you really want to test for equality you can do

!!isElement(e) === someBooleanValue

But I would expect that the vast majority of the time you would be doing

isElement(e) == someBooleanValue

Especially if you know that someBooleanValue really is definitely a
boolean.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/4534#issuecomment-28139998
.