True! or false!

ruby-talk
1

Making good use of polymorphism I had this idea for assertion methods:

  class TrueClass
    # Assert true.

···

#
    # (x == y).true!
    #
    def true!
      true
    end
    # Assert false.
    #
    # (x == y).false!
    #
    def false!
      raise "not false!"
    end
  end

  class FalseClass
    # Assert true.
    #
    # (x == y).true!
    #
    def true!
      raise "not true!"
    end
    # Assert false.
    #
    # (x == y).false!
    #
    def false!
      true
    end
  end

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

2

I believe the more idiomatic way of doing it would be with question marks,
isn't it?

.true? instead of .true!

exclamation marks are usually for destructive methods, question marks for
booleans.

···

2010/11/4 Intransition <transfire@gmail.com>

Making good use of polymorphism I had this idea for assertion methods:

class TrueClass
   # Assert true.
   #
   # (x == y).true!
   #
   def true!
     true
   end
   # Assert false.
   #
   # (x == y).false!
   #
   def false!
     raise "not false!"
   end
end

class FalseClass
   # Assert true.
   #
   # (x == y).true!
   #
   def true!
     raise "not true!"
   end
   # Assert false.
   #
   # (x == y).false!
   #
   def false!
     true
   end
end

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

3

Thomas Sawyer wrote in post #959291:

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

You could override the exception message:

class TrueClass
  def false!(err = "not false!")
    raise err
  end
end

(1 == 2).false! "Maths is broken"

You end up with something like dfect, just with different ordering of
the values.

···

--
Posted via http://www.ruby-forum.com/\.

4

You would need to override at a higher level, I think, because I frequently
use object/nil instead of true/false.

require 'test/unit'

class Object
  def true! ; self || raise("not true!") ; end
  def false! ; self && raise("not false!") ; end
end

class TrueBangFalseBang < Test::Unit::TestCase
  def test_object ; [1,2,3][2].true! ; end
  def test_non_object ; [1,2,3][3].false! ; end
  def test_true ; (1==1).true! ; end
  def test_false ; (1==2).false! ; end
end

I like it, except that it doesn't count these as assertions. Even if you mix
the assertions module into object and use the assert methods, like this:

class Object
  include Test::Unit::Assertions
  def true! ; assert self ; end
  def false! ; assert !self ; end
end

You would get results like "4 tests, 0 assertions, 2 failures", maybe if you
look even further under the hood you could figure out how to get them to
count. Or just choose to not care, but for me, that is a number I like to
see :slight_smile:

···

On Thu, Nov 4, 2010 at 5:55 AM, Intransition <transfire@gmail.com> wrote:

Making good use of polymorphism I had this idea for assertion methods:

class TrueClass
   # Assert true.
   #
   # (x == y).true!
   #
   def true!
     true
   end
   # Assert false.
   #
   # (x == y).false!
   #
   def false!
     raise "not false!"
   end
end

class FalseClass
   # Assert true.
   #
   # (x == y).true!
   #
   def true!
     raise "not true!"
   end
   # Assert false.
   #
   # (x == y).false!
   #
   def false!
     true
   end
end

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

5

Originally I did not have the exclamations at all, just `.true`, but
added them to give it some extra umph b/c it is raising an error.

A question mark would indicate that it returns either true or false.
For instance, Facets defines #true? and #false? to work like #nil?

An exclamation doesn't necessarily mean destructive --that's just it's
most common use. The actual meaning is much more general, something
like "hey, this does something more than usual!"

···

On Nov 4, 7:21 am, Louis-Philippe <defa...@spiralix.org> wrote:

I believe the more idiomatic way of doing it would be with question marks,
isn't it?

.true? instead of .true!

exclamation marks are usually for destructive methods, question marks for
booleans.

6

> Making good use of polymorphism I had this idea for assertion methods:

> class TrueClass
> # Assert true.
> #
> # (x == y).true!
> #
> def true!
> true
> end
> # Assert false.
> #
> # (x == y).false!
> #
> def false!
> raise "not false!"
> end
> end

> class FalseClass
> # Assert true.
> #
> # (x == y).true!
> #
> def true!
> raise "not true!"
> end
> # Assert false.
> #
> # (x == y).false!
> #
> def false!
> true
> end
> end

> If only the error message could say something about WHAT was not true
> or false, this could be pretty nifty.

You would need to override at a higher level, I think, because I frequently
use object/nil instead of true/false.

Could add the methods to NilClass too.

require 'test/unit'

class Object
def true! ; self || raise("not true!") ; end
def false! ; self && raise("not false!") ; end
end

Hmm... Yes, that might be better b/c then anything other then false
and nil will evaluate as true too. That is a good thing, right?

class TrueBangFalseBang < Test::Unit::TestCase
def test_object ; [1,2,3][2].true! ; end
def test_non_object ; [1,2,3][3].false! ; end
def test_true ; (1==1).true! ; end
def test_false ; (1==2).false! ; end
end

I like it, except that it doesn't count these as assertions. Even if you mix
the assertions module into object and use the assert methods, like this:

class Object
include Test::Unit::Assertions
def true! ; assert self ; end
def false! ; assert !self ; end
end

You would get results like "4 tests, 0 assertions, 2 failures", maybe if you
look even further under the hood you could figure out how to get them to
count. Or just choose to not care, but for me, that is a number I like to
see :slight_smile:

Yes, that's possible but it depends on which test framework you are
using. For MiniTest, for instance, it would probably be something
like:

  MiniTest::Assertions._assertions+=1
  raise MiniTest::Assertion.new(err)

Too bad there isn't some sort of core support for this kind of thing
that could be used across test frameworks.

···

On Nov 4, 1:31 pm, Josh Cheek <josh.ch...@gmail.com> wrote:

On Thu, Nov 4, 2010 at 5:55 AM, Intransition <transf...@gmail.com> wrote: