Prev: [ANN] Harvested 0.3.0
Next: Google Wave: A new type of "Ruby Quiz" ?
From: Josh Cheek on 12 Apr 2010 02:54
[Note: parts of this message were removed to make it a legal post.]

On Mon, Apr 12, 2010 at 12:35 AM, Albert Schlef <albertschlef(a)gmail.com>wrote:

> Albert Schlef wrote:
> > 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.
> --
> Posted via http://www.ruby-forum.com/.
>
>
Doesn't work for me, so probably from some gem.

You could do something like this:

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


class Example
attr_accessor? :abc
end

e = Example.new
e.abc = true
e.abc? # => true

e.abc = false
e.abc? # => false

e.abc = 1
e.abc? # => true

e.abc = nil
e.abc? # => false

e.abc = :adsf
e.abc? # => true




There was also a ruby quiz about attr methods
http://rubyquiz.com/quiz67.html And there is a gem based off of it
http://github.com/ahoward/fattr

I don't know where yours came from, though.

From: Intransition on 12 Apr 2010 10:15

On Apr 11, 9:13 pm, Daniel N <has....(a)gmail.com> wrote:

> 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.

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.


From: Intransition on 12 Apr 2010 10:23
On Apr 11, 9:00 pm, Albert Schlef <albertsch...(a)gmail.com> wrote:
> Let's say I have this code:
>
> class Mambo
>   attr_accesstor :safe
> end
>
> Now,
>
> 'safe', in my case, is a boolean. Problem is, the getter will be named
> 'safe', whereas I want it to be 'safe?'.

In Ruby 1.9, once can create writers with

attr :x=

I love this feature b/c it means I can just use #attr and not need the
other three attr_reader, attr_writer and attr_accessor.

It would be cool if we could make "boolean" readers too with,

attr :x?

(P.S. Is the attr :x= feature going to get back ported to 1.8.8?)

From: Bill Kelly on 12 Apr 2010 13:02
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.

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.


Regards,

Bill




From: Intransition on 12 Apr 2010 14:29


On Apr 12, 1:02 pm, Bill Kelly <bi...(a)cts.com> 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.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [ANN] Harvested 0.3.0
Next: Google Wave: A new type of "Ruby Quiz" ?