From: Intransition Date: 2010-04-13T03:29:26+09:00 Subject: Re: attr_accessor, but for a boolean On Apr 12, 1:02 pm, Bill Kelly wrote: > Intransition wrote: > > >> This way the expectation of a ? method to return a boolean is preserved. > > > I used to think this too, but... I think it was Austin Ziegler who > > made the argument against using anything like "!!". In ruby it isn't > > necessary. Anything that isn't nil or false is evaluated by > > conditionals as true. I haven't once seen a case where it mattered if > > a boolean was returned rather than the underlying value. > > In a DRb situation, I'd rather send 'true' across the wire than > an arbitrary object. That's an interesting point. > Also, if the boolean value is going to be stored somewhere, > I'd rather store a 'true' than reference an arbitrary object. I imagine the the underlying attribute (e.g. @safe) is what will be stored in any case, so if that isn't already false/true it probably won't matter in this case. > Also, if I'm adding a temporary debug printout #{someval.inspect} > it's nicer to see true/false in the output. At other times you might want to see the underlying attribute. It's easier to write '!!obj.safe?' then it is to write 'obj.instance_eval{ @safe }'. I can understand wanting it either way depending on the situation. But for an attr method I think it's probably best to side on doing less rather than more, i.e. just making :a? a normal reader. But I wouldn't bemoan it working one way or the other really.