If someone has some worthwhile reasons they can share for returning the
values, please do so. Otherwise, I would prefer not giving someone data
they might use that might not be there later. I wrote method that returned
a boolean-like value by returning !(!(something)) just to ensure exactly
true or false. The alternative is just to unnerving!
Drew
···
-----Original Message-----
From: Martin DeMello [mailto:martindemello@yahoo.com]
Sent: Saturday, August 09, 2003 8:52 AM
To: ruby-talk@ruby-lang.org
Subject: Re: Ruby and OOP-design (question of an old
“procedural person”
Well and good, but they don’t document the fact that the
return value can be used as anything other than a boolean.
Duck typing or no, I find it conceptually messy to have a
method called nonzero? return self rather than true - compare
nil? and zero?. Using the value of self feels like relying on
an undocumented side effect. (I feel the same way about !
methods returning nil rather than self when they haven’t made
a change).
If someone has some worthwhile reasons they can share for returning the
values, please do so. Otherwise, I would prefer not giving someone data
they might use that might not be there later. I wrote method that returned
a boolean-like value by returning !(!(something)) just to ensure exactly
true or false. The alternative is just to unnerving!
Drew
That all depends on what exactly you want the method to do. If #nonzero?
is defined as “returns the
number when not zero, or false otherwise,” then it’s documented that the
result can be used in that way,
which could possibly be useful in some cases.
If #nonzero? is defined as “returns a true value when not zero, and a
false value otherwise,” then there’s
no compelling reason to return anything other than true or false
exactly. However, there also isn’t much
of a compelling reason to only return true or false exactly, except
for rare cases like
1.nonzero? == 2.nonzero?, and the fact that it unnerves some.
However, many people don’t have a problem with it, so perhaps it’s just
something you get used to
over time. As long as you test adequately, it shouldn’t make a
difference one way or the other in practice.
Dan
P.S.: The above can be written (1 != 0) == (2 != 0), which is shorter to
type, even, so one could
argue that perhaps #nonzero? ought to provide different functionality,
which it does, currently.