Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > true! or false!

Reply
Thread Tools

true! or false!

 
 
Intransition
Guest
Posts: n/a
 
      11-04-2010
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.

 
Reply With Quote
 
 
 
 
Louis-Philippe
Guest
Posts: n/a
 
      11-04-2010
[Note: parts of this message were removed to make it a legal post.]

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 <(E-Mail Removed)>

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


 
Reply With Quote
 
 
 
 
Intransition
Guest
Posts: n/a
 
      11-04-2010


On Nov 4, 7:21=A0am, Louis-Philippe <(E-Mail Removed)> 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.


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!"

 
Reply With Quote
 
Brian Candler
Guest
Posts: n/a
 
      11-04-2010
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/.

 
Reply With Quote
 
Josh Cheek
Guest
Posts: n/a
 
      11-04-2010
[Note: parts of this message were removed to make it a legal post.]

On Thu, Nov 4, 2010 at 5:55 AM, Intransition <(E-Mail Removed)> 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.
>
>

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

 
Reply With Quote
 
Intransition
Guest
Posts: n/a
 
      11-04-2010


On Nov 4, 1:31=A0pm, Josh Cheek <(E-Mail Removed)> wrote:
> On Thu, Nov 4, 2010 at 5:55 AM, Intransition <(E-Mail Removed)> wrote:
> > Making good use of polymorphism I had this idea for assertion methods:

>
> > =A0class TrueClass
> > =A0 =A0# Assert true.
> > =A0 =A0#
> > =A0 =A0# =A0 (x =3D=3D y).true!
> > =A0 =A0#
> > =A0 =A0def true!
> > =A0 =A0 =A0true
> > =A0 =A0end
> > =A0 =A0# Assert false.
> > =A0 =A0#
> > =A0 =A0# =A0 (x =3D=3D y).false!
> > =A0 =A0#
> > =A0 =A0def false!
> > =A0 =A0 =A0raise "not false!"
> > =A0 =A0end
> > =A0end

>
> > =A0class FalseClass
> > =A0 =A0# Assert true.
> > =A0 =A0#
> > =A0 =A0# =A0 (x =3D=3D y).true!
> > =A0 =A0#
> > =A0 =A0def true!
> > =A0 =A0 =A0raise "not true!"
> > =A0 =A0end
> > =A0 =A0# Assert false.
> > =A0 =A0#
> > =A0 =A0# =A0 (x =3D=3D y).false!
> > =A0 =A0#
> > =A0 =A0def false!
> > =A0 =A0 =A0true
> > =A0 =A0end
> > =A0end

>
> > 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 frequent=

ly
> use object/nil instead of true/false.


Could add the methods to NilClass too.

> require 'test/unit'
>
> class Object
> =A0 def true! =A0 ; =A0self || raise("not true!") =A0 ; =A0end
> =A0 def false! =A0; =A0self && raise("not false!") =A0; =A0end
> 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
> =A0 def test_object =A0 =A0 =A0 ; =A0[1,2,3][2].true! =A0 ; =A0end
> =A0 def test_non_object =A0 ; =A0[1,2,3][3].false! =A0; =A0end
> =A0 def test_true =A0 =A0 =A0 =A0 ; =A0(1=3D=3D1).true! =A0 =A0 =A0 ; =A0=

end
> =A0 def test_false =A0 =A0 =A0 =A0; =A0(1=3D=3D2).false! =A0 =A0 =A0; =A0=

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
> =A0 include Test::Unit::Assertions
> =A0 def true! =A0 ; =A0assert self =A0 ; =A0end
> =A0 def false! =A0; =A0assert !self =A0; =A0end
> 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


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+=3D1
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments