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

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

Comments

Projects
None yet
6 participants
@myronmarston
Member

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?

@samphippen

This comment has been minimized.

Show comment
Hide comment
@samphippen

samphippen Jul 7, 2013

Member

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

Member

samphippen 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

This comment has been minimized.

Show comment
Hide comment
@cupakromer

cupakromer Jul 7, 2013

Member

👍

Member

cupakromer commented Jul 7, 2013

👍

@alindeman

This comment has been minimized.

Show comment
Hide comment
@alindeman

alindeman Jul 7, 2013

Contributor

I think this is a good idea.

Contributor

alindeman commented Jul 7, 2013

I think this is a good idea.

@JonRowe

This comment has been minimized.

Show comment
Hide comment
@JonRowe

JonRowe Jul 10, 2013

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@soulcutter

soulcutter Jul 11, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@soulcutter

soulcutter Jul 11, 2013

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Jul 11, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Jul 11, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@alindeman

alindeman Jul 11, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@soulcutter

soulcutter Jul 11, 2013

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Jul 11, 2013

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@alindeman

alindeman Jul 11, 2013

Contributor

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

Contributor

alindeman commented Jul 11, 2013

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

@soulcutter

This comment has been minimized.

Show comment
Hide comment
@soulcutter

soulcutter Jul 11, 2013

Member

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

Member

soulcutter commented Jul 11, 2013

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

@samphippen

This comment has been minimized.

Show comment
Hide comment
@samphippen

samphippen Jul 11, 2013

Member

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).

Member

samphippen 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

This comment has been minimized.

Show comment
Hide comment
@JonRowe

JonRowe Jul 12, 2013

Member

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 ;)

Member

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Jul 12, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Aug 22, 2013

Member

This has been addressed.

Member

myronmarston commented Aug 22, 2013

This has been addressed.

@yujinakayama yujinakayama referenced this issue in yujinakayama/transpec Sep 30, 2013

Closed

Support conversion to `be_truthy` / `be_falsey` #8

@allolex allolex referenced this issue in Hello-Labs/suretax Dec 21, 2013

Merged

Better responses #9

@myronmarston myronmarston referenced this issue Jan 1, 2014

Merged

Support composable matchers #393

10 of 10 tasks complete

@floere floere referenced this issue in floere/phony Jan 5, 2014

Closed

Prepare for RSpec 3.x #127

@ck3g ck3g referenced this issue in CanCanCommunity/cancancan Jun 4, 2014

Closed

Bumps rspec to 3.0.0 (release) and fixes deprecation warnings #4

joshcooper added a commit to puppetlabs/puppetlabs-powershell that referenced this issue Jun 7, 2014

(maint) Remove rspec 3 deprecations
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

Prefer `be_falsey` over `be_falsy`
* 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 jessieay referenced this issue in thoughtbot/guides Jun 13, 2014

Merged

Avoid checking boolean equality directly #191

jessieay added a commit to thoughtbot/guides that referenced this issue Jun 13, 2014

Prefer `be_falsey` over `be_falsy`
* 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

@tgaff tgaff referenced this issue in natritmeyer/site_prism Jul 1, 2014

Closed

resolve test-suite incompatibilities with rspec3 #77

@iamvery iamvery referenced this issue in tdouce/remote_factory_girl Aug 15, 2014

Closed

Failing test suite? #8

@gluxon gluxon referenced this issue in fhsav/clock Sep 10, 2014

Closed

Upgrade to RSpec 3.1 #363

tomoyukikashiro added a commit to tomoyukikashiro/railstutorial.jp that referenced this issue Dec 6, 2014

@tomoyukikashiro tomoyukikashiro referenced this issue in yasslab/railstutorial.jp Dec 6, 2014

Closed

rename to_false -> to_falsey #14

@gdpelican gdpelican referenced this issue in loomio/loomio Feb 15, 2015

Merged

replace should == in tests #1909

repinel added a commit to repinel/carrierwave-mongoid that referenced this issue May 21, 2015

Replace deprecated rspec conditional expectations
`be_true` and `be_false` were deprecated in `rspec-2.99` and removed in
`rspec-3.0`.

rspec/rspec-expectations#283

@repinel repinel referenced this issue in carrierwaveuploader/carrierwave-mongoid May 21, 2015

Merged

Replace deprecated rspec conditional expectations #146

@monfresh monfresh referenced this issue in 18F/identity-idp May 25, 2016

Merged

Update password requirements #112

marcandre added a commit to marcandre/bundler-cases that referenced this issue Aug 29, 2016

@marcandre marcandre referenced this issue in chrismo/bundler-cases Aug 29, 2016

Merged

Don't use be_true. #4

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

Updated gems dependencies and solved deprecation warnings
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