Hi Just noticed that the behaviour of @cow.should_not be_hungry is not the same as @cow.hungry?.should == false # nil also passes Don''t know how this has escaped me for so long =) What''s the thinking behind this? You can already do @cow.hungry?.should(_not) be_nil so surely it makes more sense for be_true and be_false to check for booleans? Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran http://aviewfromafar.net/ http://twitter.com/ashleymoran
On Fri, Mar 13, 2009 at 5:17 AM, Ashley Moran >> Just noticed that the behaviour of > > ?@cow.should_not be_hungry > > is not the same as > > ?@cow.hungry?.should == false # nil also passes > > Don''t know how this has escaped me for so long =) > > What''s the thinking behind this? ?You can already do > > ?@cow.hungry?.should(_not) be_nil > > so surely it makes more sense for be_true and be_false to check for > booleans?In common Ruby use, nil is usually treated the same as false, so that''s the way the dynamic matcher works - it''s the most convenent. You see explicit comparisons against true or false pretty rarely (in my experience). Unless you have a specific need for a three-valued truth system (e.g., true, false, and unknown), I think it''s best practice not to assume that if !x == true, then x must == false, and vice versa. ///ark
On Mar 13, 2009, at 5:17 AM, Ashley Moran wrote:> Hi > > Just noticed that the behaviour of > > @cow.should_not be_hungry > > is not the same as > > @cow.hungry?.should == false # nil also passes > > Don''t know how this has escaped me for so long =) > > What''s the thinking behind this? You can already do > > @cow.hungry?.should(_not) be_nil > > so surely it makes more sense for be_true and be_false to check for > booleans?be_true and be_false do check for booleans :) but you didn''t use either of them. The expanded form of @cow.should_not be_hungry is @cow.hungry?.should_not be Pat
On 13 Mar 2009, at 15:42, Pat Maddox wrote:> On Mar 13, 2009, at 5:17 AM, Ashley Moran wrote: > >> Hi >> >> Just noticed that the behaviour of >> >> @cow.should_not be_hungry >> >> is not the same as >> >> @cow.hungry?.should == false # nil also passes >> >> Don''t know how this has escaped me for so long =) >> >> What''s the thinking behind this? You can already do >> >> @cow.hungry?.should(_not) be_nil >> >> so surely it makes more sense for be_true and be_false to check for >> booleans? > > be_true and be_false do check for booleans :) but you didn''t use > either of them. > > The expanded form of > @cow.should_not be_hungry > is > @cow.hungry?.should_not be > > PatLike yoda sounds, that does Matt Wynne http://blog.mattwynne.net http://www.songkick.com
On 13 Mar 2009, at 16:34, Matt Wynne wrote:>> The expanded form of >> @cow.should_not be_hungry >> is >> @cow.hungry?.should_not be >> >> Pat > > Like yoda sounds, that doesAnd enlightened, I am =) Thanks Pat -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran http://aviewfromafar.net/ http://twitter.com/ashleymoran
On 13 Mar 2009, at 16:34, Matt Wynne wrote:> Like yoda sounds, that doesBeen implemented properly, it has :) http://blog.zenspider.com/2009/04/spec-yoda-will.html -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran http://aviewfromafar.net/ http://twitter.com/ashleymoran