On Mon, Apr 12, 2010 at 10:00:06AM +0900, Albert S. wrote:
In other words, how do I make the getter ‘safe?’ and the setter ‘safe’
?
In situations like this, I make two “getters” and leave the assignment
alone. Other ruby programmers expect your “setters” to be in the form
of “obj.safe = true”, not “obj.safe(true)”.
Try something like this:
class Mambo
attr_accesstor :safe
alias :safe? :safe
end
Here it is in action:
irb(main):001:0> class Mambo
irb(main):002:1> attr_accessor :safe
irb(main):003:1> alias :safe? :safe
irb(main):004:1> end
=> nil
irb(main):005:0> m = Mambo.new
=> #<Mambo:0x000001010cab50>
irb(main):006:0> m.safe = true
=> true
irb(main):007:0> m.safe?
=> true
irb(main):008:0>
‘safe’, whereas I want it to be ‘safe?’.
class Mambo
=> nil http://tenderlovemaking.com/
Unfortunately this doesn’t support safe? being boolean always. It could
be
something other than true false (may not be a problem)
If you want to use attr_accessor rather than simply aliasing the method
I’d
suggest
def safe?
!!safe
end
This way the expectation of a ? method to return a boolean is preserved.
Thank you both. I wanted to make sure there’s no built-in way to do
this.
Hey, I’ve just discovered that ‘ri’ tells me that Module has an
‘attr_reader?’ method that creates a question-mark attribute.
Problem is, ‘ri’ displays methods from everything I’ve installed on my
system, so I can’t know if ‘attr_reader?’ is provided by Ruby itself or
by some wacky gem.
class Module
def attr_accessor?(*methods)
methods.each do |method|
ivar = “@#{method}”
define_method(“#{method}=”) { |value| instance_variable_set ivar ,
value }
define_method(“#{method}?”) { !!instance_variable_get(ivar) }
end
end
end
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 Z. 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.
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 Z. 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.
Also, if the boolean value is going to be stored somewhere,
I’d rather store a ‘true’ than reference an arbitrary object.
Also, if I’m adding a temporary debug printout #{someval.inspect}
it’s nicer to see true/false in the output.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.