"Nicholas Van Weerdenburg" <nick / activehitconsulting.com> wrote in message
news:40ABFE84.4090509 / activehitconsulting.com...
> ... 3 things evaluate to a boolean- an objects existence, it's
> non-existence, or a boolean. The first two being nice shortcuts.

Maybe it's the latter that's the nice shortcut, an object's existence or not
being primal: see [ruby-talk:100755].

What may be a useful addition to this situation (of legacy (eg libraries')
treatment of 0 return values as false), I think, is a to_bool that is
analogous NOT to to_s, but to to_str:
* it would not be implemented in base classes, and probably not in Integer
or its relatives, either;
* it would obviously be not be automatically called by conditionals
* it could be added to an Integer subclass

I realise after these dot-points that this is not well-thought-out at all -- 
what core classes are enough like booleans to implement this method by
default?

There's probably more merit in having wrappers of legacy libraries behave
more rubyishly by returning nil when appropriate. A return-code class? Now
I'm just babbling.

At least, adding a to_bool to a class or a select few classes seems to be
the rubyishest way to get this kind of behaviour if, for whatever reason,
you deem it necessary. Things shouldn't have to quack true or false.