From: Matthew Moss <matthew.moss.coder@...>
Date: 2006-02-09T08:29:21+09:00
Subject: Re: boolean annoyance

> > Because if I'm expecting an integer and zero is a legal
> > value, then you have to start playing around in your conditionals...
>
> If you are inspecting a integer against nothing end everything is just
> legal, why are you inspecting it?

I didn't say everything was legal; I said zero could be legal. That
does not imply everything is legal.

I typically see this in C/C++ where someone has written a function
where 0 is a legal value, they then return a negative number for
illegal status.  But, IMO, now you start building maintainence
headaches, since some function calls look like:

  if (foo(...))

and others look like:

  if (foo(...) < 0)


Ruby just takes the stance (as do many other languages) that there
shall no automatic determination of what integers are valid and which
are invalid, and that shall be left to the coder.


> The difference between NULL and nil is not that big. Did you ever try to
> do stuff like nil.split or nil.capitalize.

Yes, I have.  Not those particular methods, but others.  Just type
'nil.methods' in irb and you can see what's defined.  And nil could be
expanded if needed (although, I suspect, generally not a good idea,
but possible).  Hell, you could do this if you really wanted to have
some excitement:

class NilClass
   def method_missing(m) nil end
end


NULL, on the other hand, is zero. Not an object.

> In ruby you have two ways of living with nil. Either you catch exections
> created by nil access all over the place or check for access. This is
> similar to C the only difference is that in C you get a SIGSEGV.

I contend that exceptions are a better solution that SIGSEGV.  As far
as checking for nil, I don't have as much experience here w/Ruby as
some others, but I've never had to put nil checking all over the
place.  Only about as often as I might branch otherwise.


> Sure 0 is an integer but it is a special one.

It is only special by convention.

> Side node: a & b is a boolean expression a bitwise boolean expression but
> still boolean.

a & b is an integer expression, implicitly typecast in C/C++ to
boolean because zero is treated as false.  Implicit typecasting can be
a dangerous thing.  The way to write a boolean expression is (a & b)
!= 0.


> Wow. I was told that the cool thing about ruby is to write less code.

There is a limit, of course. You could remove constant names, change
function identifiers to single letters, remove whitespace, etc.  All
that is writing less code, but I'd hesitate to do it.

I prefer to think that Ruby lets me write clearer code, quickly,
easily, and that often amounts to less code, in part because it is a
dynamic language (as compared to how much code I often have to write
in C++ because of it's static nature).

Still being a fairly new Ruby user, I would never write:
    if (a & b)
Yes, of course, because it doesn't work, but I also wouldn't write:
    if (a & b).nonzero?

Now I did mention that in my post, but it was to lead you to better
ways.  Something like:

class State
   def visible?
      @flags[0x01].nonzero?
   end
end

state = State.new
# ... do stuff ...
draw_scene if stat.visible?

"if stat.visible?" is much more readable that "if flags & 0x01" or the like.