Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider renaming `be_true` and `be_false` to `be_truthy` and `be_falsey` #283

Closed
myronmarston opened this issue Jul 7, 2013 · 17 comments
Closed

Comments

@myronmarston
Copy link
Member

@myronmarston myronmarston commented Jul 7, 2013

I've heard some grumbling about this recently, and I've always found it a bit puzzling as well. be_true and be_false really act like be_truthy and be_falsey but aren't named as such. I think lots of folks think be_true passes if and only if the value is true, and be_false passes if and only if the value is false but that's not the case. You can already do be true and be false (no underscore) for the exact match, so I don't think there's any need to change the semantics of be_true and be_false -- instead, I'd like to deprecate them, in favor of be_truthy and be_falsey, which are more accurately named. Thoughts?

@penelopezone
Copy link
Member

@penelopezone penelopezone commented Jul 7, 2013

👍 I could implement this tomorrow if we're there right now, or do you want to get some community feedback first?

@cupakromer
Copy link
Member

@cupakromer cupakromer commented Jul 7, 2013

👍

@alindeman
Copy link
Contributor

@alindeman alindeman commented Jul 7, 2013

I think this is a good idea.

@JonRowe
Copy link
Member

@JonRowe JonRowe commented Jul 10, 2013

@samphippen's PR's LGTM, but I'm not really in favour of this change, I've never liked 'Truthy' or 'Falsey' as terms so I kind of feel it's a backwards step in terms of language for some extra pedantry... I've always used be_true meaning "to be truthy" and from my observation it's always been the ruby way to treat the two interchangeably.

That said I'd have nothing against adding be_truthy as well as be_true. I've always been more specific when I want actually true.

@soulcutter
Copy link
Member

@soulcutter soulcutter commented Jul 11, 2013

I agree with @JonRowe - truthy/falsey are unlikely to be expected to exist, where be_true / be_false are expected to exist. I also feel that the whole true vs truthy thing is a rubyism, and rubyists expect true and false to mean "evaluate as true" or "evaluate as false".

I also know that this change will affect a LOT of people. Is it adding enough value to make it worth it? I don't think so.

@soulcutter
Copy link
Member

@soulcutter soulcutter commented Jul 11, 2013

I'm on the fence. I realized there is some parity with Jasmine having truthy/falsey (they call it falsy btw). Maybe it makes sense to continue to support it with warnings for a while (until rspec 4 even?). Or indefinitely?

@myronmarston
Copy link
Member Author

@myronmarston myronmarston commented Jul 11, 2013

I agree with @JonRowe - truthy/falsey are unlikely to be expected to exist, where be_true / be_false are expected to exist. I also feel that the whole true vs truthy thing is a rubyism, and rubyists expect true and false to mean "evaluate as true" or "evaluate as false".

Maybe I'm an exception, but I think of non-nil, non-false objects as "being treated as true", but I don't think of them as "being true". I think it's also quite confusing that the semantics and meaning of be true and be_true are different (and likewise, be_false and be false are different). I've heard a bit of grumbling in the community about this as well; here's one example.

All that said, maybe we should invite community discussion on this? I can mention and link to this from the rspec 3 blog post that'll be going live next week if you like.

@myronmarston
Copy link
Member Author

@myronmarston myronmarston commented Jul 11, 2013

That said I'd have nothing against adding be_truthy as well as be_true. I've always been more specific when I want actually true.

@JonRowe -- if we move this direction, I'd definitely want be_true removed (sans some deprecation period, which may just be 2.99). I think the difference between be true and be_true is confusing, given that they read aloud exactly the same, and that an underscore is really just a stand-in for a space in a code identifier.

@alindeman
Copy link
Contributor

@alindeman alindeman commented Jul 11, 2013

Maybe I'm an exception, but I think of non-nil, non-false objects as "being treated as true", but I don't think of them as "being true". I think it's also quite confusing that the semantics and meaning of be true and be_true are different (and likewise, be_false and be false are different). I've heard a bit of grumbling in the community about this as well; here's one example.

I agree. It definitely confused me at first. Given Ruby is a strongly typed language, be_true feels like it should mean == true (and that's what you get with be true).

All that said, maybe we should invite community discussion on this? I can mention and link to this from the rspec 3 blog post that'll be going live next week if you like.

I'm a little concerned about community discussion here because I'm not sure what other rationale could be brought up at this point other than personal preferences and personal ways of internalizing true/false in Ruby. We might cause a lot of useless noise over it? But I might be thinking too hard.

@soulcutter
Copy link
Member

@soulcutter soulcutter commented Jul 11, 2013

Well, I don't disagree with @myronmarston 's points, I guess it's positive to remove the ambiguity between be_true / be true.

@myronmarston
Copy link
Member Author

@myronmarston myronmarston commented Jul 11, 2013

BTW, I don't have a strong opinion on be_falsy vs be_falsey. falsey seems to be the more common term based on number of google results, though:

falsy - google search

falsey - google search

@alindeman
Copy link
Contributor

@alindeman alindeman commented Jul 11, 2013

Given that there are some results for both, maybe we alias them?

@soulcutter
Copy link
Member

@soulcutter soulcutter commented Jul 11, 2013

In fairness I believe Falsey gets used as a surname, so there's that...

@penelopezone
Copy link
Member

@penelopezone penelopezone commented Jul 11, 2013

Injecting opinions:

I agree with @alindeman, I don't think we need to do a community consult here (for the reasons he listed). I do think we should alias falsey and falsy. I do think we should remove be_true and be_false with deprecation period in 2-99 (otherwise we're obliged to keep them until 4).

@JonRowe
Copy link
Member

@JonRowe JonRowe commented Jul 12, 2013

An alternative way of removing confusion would be to make be true behave like be_true does now, and encourage people to use eq true when they actually want a direct comparison.

Although if we do go with this my 2¢ is that I'd favour falsey over falsy because falsey is the same number of chars as truthy and I like the parity ;)

@myronmarston
Copy link
Member Author

@myronmarston myronmarston commented Jul 12, 2013

An alternative way of removing confusion would be to make be true behave like be_true does now, and encourage people to use eq true when they actually want a direct comparison.

I think this would increase confusion. The be matcher has well known and documented semantics that state that be x is precisely the same as equal?(x). Special casing it for one value would create tons of confusion. It would get worse when you are dealing with a variable (e.g. expect(x).to be y -- suddenly the value of y would determine how the matcher operates; if it's true it would act one way and if it's a normal ruby object it would act another way.

I like the idea of aliasing be_falsey and be_falsy so that either can be used.

@myronmarston
Copy link
Member Author

@myronmarston myronmarston commented Aug 22, 2013

This has been addressed.

@myronmarston myronmarston mentioned this issue Jan 1, 2014
10 of 10 tasks complete
joshcooper added a commit to puppetlabs/puppetlabs-powershell that referenced this issue Jun 7, 2014
Rspec 3 deprecates `be_true` and `be_false` because they
actually behave like `be_truthy` and `be_falsey`[1].

This commit uses changes them to match exactly true or false.

[1] rspec/rspec-expectations#283
jessieay added a commit to thoughtbot/guides that referenced this issue Jun 13, 2014
* In RSpec 3, `be_false` and `be_true` are deprecated in favor of
* `be_falsey` and `be_truthy`
* Source: rspec/rspec-expectations#283
* `be_falsy` works but is just an alias for `be_falsey` so we should prefer the
  latter
jessieay added a commit to thoughtbot/guides that referenced this issue Jun 13, 2014
* In RSpec 3, `be_false` and `be_true` are deprecated in favor of
  `be_falsey` and `be_truthy`
* Source: rspec/rspec-expectations#283
* `be_falsy` works but is just an alias for `be_falsey` so we should prefer the
  latter
tomoyukikashiro added a commit to tomoyukikashiro/railstutorial.jp that referenced this issue Dec 6, 2014
repinel added a commit to repinel/carrierwave-mongoid that referenced this issue May 21, 2015
`be_true` and `be_false` were deprecated in `rspec-2.99` and removed in
`rspec-3.0`.

rspec/rspec-expectations#283
marcandre added a commit to marcandre/bundler-cases that referenced this issue Aug 29, 2016
marcandre added a commit to marcandre/bundler-cases that referenced this issue Aug 30, 2016
dvergeylen added a commit to dvergeylen/omniauth-identity that referenced this issue Apr 5, 2017
This unfortunately drops support of mongo_mapper due to this: mongomapper/mongomapper#631
As mongo_mapper still uses mongo driver 1.8, it creates an incompatibility between mongo_mapper and mongoid drivers.
As mongo driver has been rewritten for mongoid, this means mongo_mapper will soon follow to support 2.x drivers.

See: rspec/rspec-expectations#283 for deprecation warnings explanations
See: rails/activemodel-serializers-xml#8 for serializer splits in separate gems
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.