Attr

ruby-talk
21

I personally always define them as:
def a?
       !!@a
end

Nice, thanks.

T

22

Gavin Kistner wrote:

···

On Jan 24, 2005, at 9:25 AM, Robert Klemme wrote:

. def a?
. @a ? true : @a
. end

Why not "def a?() @a end"?

I personally always define them as:
def a?
    !!@a
end

Ick. I know it's easy to add, but I really think there should be a standard Object#to_bool that returns a standard Boolean object, of which TrueClass and FalseClass are subclasses.

Not having them incourages this kind of hackery, which (if you know Ruby) is a neat trick. If you don't know Ruby it's Perl linenoise.

Ben

23

Robert Klemme wrote:

So you want to protect the real value. Is that the reasoning behind

this?

Not exactly. It is simply one readibility really and overlapping
functionality. For instance if you saw:

case a?

What would you expect to be in the when clauses? It's customary to
expect a mthod ending in ? to return a "boolean" (true, false, nil).
You wouldn;t expect to see something like:

a?.kind_of(Integer)

That's not to say you can't do it if you want, but is atypical. You
would just use 'a.kind_of(Integer)'.

Still you introduce a method in class Module that has some special

behavior

which at least clutters namespace - even if unused. As Module is a

very

basic class it's behavior should be most general, too - my 0.02 EUR.

I don;t see how it clutters namespace. It's one method. The special
behavior is quite basic, so I don't see how that's really get in the
way. But I guess that's my 2 cents too.

(You can always define an add on that adds these methods.)

Isn't that what I'm doing?

>> Also you might want to be able to assign and to replace...
>
> I think you'd just replace first from the calling routine, and then
> assign. Or perhaps I misunderstand?

I meant that with only the replace version of the method there is no

option

to assign to the member var. But with the getter you can already

replace.

Of course, a.c! "foo" is shorter than a.c.replace "foo" - but then

again,

it's a special case as it applies only to String (or at least

mostly). :slight_smile:

Sure. I don't think the ! notaiton will be of great use. But niether is
the current definition of #attr. I just gave it something to do that's
simple and straigh foward that goes along with the gernal meaning of !
on the end of a method. But perhaps you have better use for the
notation?

> Ah, but there are many advantages, not just the fact that attr is
> shorter. You can define both readers and writers in the same call.

I can do that with attr_accessor.

No becasue you get both a reader and a writer for each. What I mean is:

attr :a, :b=

Is one reader and one writer.

> The
> names of the methods defined are returned so you can use public,
> private, protected (and user defined methods too!) in front of

them.

This works only if the method returns a single symbol. Otherwise

it's going

to be ugly:

class Module
  def a(*x) :single end
  def b(*x) [:a,:b] end
end

class Foo
  def single; end
  def a;end
  def b;end

  private a :a, :b
  private b :c, :d # doesn't work
  private *b :c, :d # doesn't work
  private *b( :c, :d) # ugly
end

Yes, that's something I have a distate for in Ruby --that there's no
way to pass through arguments-per-arguments via return. I.e.

  def self.b(*x) ; return *x ; end
  private b

#b still returns an array with or without the * in 'return *x', it
seems. But there is of course the solution of altering public, private
and protected to accept an array.

> They also route through a common #define_attribute method, so there

is

> central control, and it stores all defined attribute methods so you

can

> ask for a list of them. It also has casting, somthing I came up

with a

> few years ago. Eg.
> . attr :a => :to_s
>
> which defines
>
> . def a
> . @a.to_s
> . end

Interesting.

I'm sorry that I don't share your enthusiasm - I simply don't miss

this

functionality.

Why would you miss it? You have never had it :slight_smile: I have been using for
awhile now. Most of the time it's of small consequence. But every once
in a while these extra "touches" come in quite handy.

T.

24

Could you rerun with /^\s+attr\s+\:/' since attr can be used for other
things too?

Nonetheless that's still pretty low and and I suspect that many
occurances are also only a matter of example --not even real use. But
I realize it does get used occasionally. I'm simply wonder if it is
enough at this point to warrant continued support? Is there some
complelling reason to use it rather than the vastly more common attr_*
methods? I don't see any reason to do so. It's a nice short method name
and it would nice if it were actually more useful, rather then just an
obsure and rarely used anomally.

Anyway I am willing to change the name (any suggestions?) or at least
make it backward compatible (any reasons not to do that?)

BTW I wonder about how #attr works. Hal wrote in his book that #attr
creates the @var and the method(s) #var/#var=. How does it "create" the
instance var? Doesn't it actually just create the methods and the
instance var gets created via their use?

T.

25

Thanks David,

Okay, I've been convicned that ! attr as defined is utterly useless. So
I'll drop it. Maybe someone will think of a good use down the line.

T.

26

Sure, but it is occasionally useful, especially when creating classes
that have many optional "initialization" parameters. Here's the
traditional-styled version. I use "setter" for lack of a better word.

# attr_setter :a

···

#
# _is equivalent to_
#
# def a(*args)
# if args.size > 0
# @a = args[0]
# self
  # else
  # @a
  # end
  # end

T.

27

Trans wrote:

> I personally always define them as:
> def a?
> !!@a
> end

Nice, thanks.

Oops. Except that with Ruby it's not a simple as true and false, there
is also nil. I think passing nil through unchanged is advantageous as
it allows for yes, no, maybe (i.e. three state) value.

T.

28

"Trans" <transfire@gmail.com> schrieb im Newsbeitrag
news:1106596384.807612.72140@c13g2000cwb.googlegroups.com...

Robert Klemme wrote:
> So you want to protect the real value. Is that the reasoning behind
this?

Not exactly. It is simply one readibility really and overlapping
functionality. For instance if you saw:

> case a?

What would you expect to be in the when clauses? It's customary to
expect a mthod ending in ? to return a "boolean" (true, false, nil).
You wouldn;t expect to see something like:

> a?.kind_of(Integer)

Not exactly. But since Ruby can treat any object properly in a boolean
context, why waste some processing cycles on conversion if not because of
information hiding (i.e. prevent leakage of a member value)?

That's not to say you can't do it if you want, but is atypical. You
would just use 'a.kind_of(Integer)'.

Or rather "Integer === a". :slight_smile:

> Still you introduce a method in class Module that has some special
behavior
> which at least clutters namespace - even if unused. As Module is a
very
> basic class it's behavior should be most general, too - my 0.02 EUR.

I don;t see how it clutters namespace. It's one method. The special
behavior is quite basic, so I don't see how that's really get in the
way. But I guess that's my 2 cents too.

Now we got 0.04 already. :slight_smile:

> (You can always define an add on that adds these methods.)

Isn't that what I'm doing?

I thought you were proposing to exchange the default behavior.

> >> Also you might want to be able to assign and to replace...
> >
> > I think you'd just replace first from the calling routine, and then
> > assign. Or perhaps I misunderstand?
>
> I meant that with only the replace version of the method there is no
option
> to assign to the member var. But with the getter you can already
replace.
> Of course, a.c! "foo" is shorter than a.c.replace "foo" - but then
again,
> it's a special case as it applies only to String (or at least
mostly). :slight_smile:

Sure. I don't think the ! notaiton will be of great use. But niether is
the current definition of #attr. I just gave it something to do that's
simple and straigh foward that goes along with the gernal meaning of !
on the end of a method. But perhaps you have better use for the
notation?

> > Ah, but there are many advantages, not just the fact that attr is
> > shorter. You can define both readers and writers in the same call.
>
> I can do that with attr_accessor.

No becasue you get both a reader and a writer for each. What I mean is:

attr :a, :b=

Ah, ok I see. Thx for clarifying.

Is one reader and one writer.

> > The
> > names of the methods defined are returned so you can use public,
> > private, protected (and user defined methods too!) in front of
them.
>
> This works only if the method returns a single symbol. Otherwise
it's going
> to be ugly:
>
> class Module
> def a(*x) :single end
> def b(*x) [:a,:b] end
> end
>
> class Foo
> def single; end
> def a;end
> def b;end
>
> private a :a, :b
> private b :c, :d # doesn't work
> private *b :c, :d # doesn't work
> private *b( :c, :d) # ugly
> end

Yes, that's something I have a distate for in Ruby --that there's no
way to pass through arguments-per-arguments via return. I.e.

> def self.b(*x) ; return *x ; end
> private b

#b still returns an array with or without the * in 'return *x', it
seems. But there is of course the solution of altering public, private
and protected to accept an array.

Hm....

> > They also route through a common #define_attribute method, so there
is
> > central control, and it stores all defined attribute methods so you
can
> > ask for a list of them. It also has casting, somthing I came up
with a
> > few years ago. Eg.
> > . attr :a => :to_s
> >
> > which defines
> >
> > . def a
> > . @a.to_s
> > . end
>
> Interesting.
>
> I'm sorry that I don't share your enthusiasm - I simply don't miss
this
> functionality.

Why would you miss it? You have never had it :slight_smile: I have been using for
awhile now. Most of the time it's of small consequence. But every once
in a while these extra "touches" come in quite handy.

But you didn't have it either and apparently you missed it, didn't you?
:wink:

Regards

    robert

29

Trans wrote:

Thanks David,

Okay, I've been convicned that ! attr as defined is utterly useless. So
I'll drop it. Maybe someone will think of a good use down the line.

There is already a use, followed by a verb the ! signifies that the receiver is going to be modified.

Zach

30

Trans wrote:

Trans wrote:

I personally always define them as:
def a?
      !!@a
end

Nice, thanks.

Oops. Except that with Ruby it's not a simple as true and false, there
is also nil. I think passing nil through unchanged is advantageous as
it allows for yes, no, maybe (i.e. three state) value.

I have failed to see when using three state's is needed. Could you provide an example where "my_obj.a?" would behave different if nil/false meant nil/maybe ?

Thanks,

Zach

31

Not exactly. But since Ruby can treat any object properly in
a boolean context, why waste some processing cycles on
conversion if not because of information hiding (i.e. prevent
leakage of a member value)?

Well, that wasn't my reasoning when I did it that way. I just thought
it should return boolean (or nil) as one would likely expect from a
?-method. But I see your point too. But perhaps this information hiding
provides it with some merit offsetting the down side of the extra
processing?

But you didn't have it either and apparently you missed
it, didn't you? :wink:

:-} He he. I suppose so. Well, it started with the casting and sort of
just grew from there.

T.

32

Hi --

Trans wrote:

Thanks David,

Okay, I've been convicned that ! attr as defined is utterly useless. So
I'll drop it. Maybe someone will think of a good use down the line.

There is already a use, followed by a verb the ! signifies that the receiver is going to be modified.

It often does signify that, but it doesn't have to. Matz has
described it as follows:

   In Scheme, every destructive operation has bang sign at the end of
   the name. Ruby did not follow this principle, rather I choose to
   put bang sign at the end of the name of methods which are more
   dangerous than alternative.

David

···

On Wed, 26 Jan 2005, Zach Dennis wrote:

--
David A. Black
dblack@wobblini.net

33

I think he means nil to be the maybe. For instance, in the ri
libraries, a few of the method signatures look like this:

  def get_method_stuff(klass, method, is_class_method = nil)

if is_class_method is true, it only looks for the method in the class
method namespace. if false, it only looks in the instance method
namespace But if it gets nil, it checks both; because it takes nil to
mean "unspecified".

Personally, I'm a little wary of this kind of stuff; I think I'd
prefer to use symbol flags:

  # method_type can be :class, :instance, or :either
  def get_method_stuff(klass, method, method_type = :either)

But still, the three-state true/false/nil way does seem to have some
precedence in the standard library.

cheers,
Mark

···

On Sat, 12 Feb 2005 06:31:19 +0900, Zach Dennis <zdennis@mktec.com> wrote:

Trans wrote:
> Trans wrote:
>
>>>I personally always define them as:
>>>def a?
>>> !!@a
>>>end
>>
>>Nice, thanks.
>
>
> Oops. Except that with Ruby it's not a simple as true and false, there
> is also nil. I think passing nil through unchanged is advantageous as
> it allows for yes, no, maybe (i.e. three state) value.
>

I have failed to see when using three state's is needed. Could you
provide an example where "my_obj.a?" would behave different if nil/false
meant nil/maybe ?

34

If a set of documents need to be "approved" for
external release -
  True means they're approved
  False means they've been reviewed and are not allowed to be released
  nil means they're not reviewed yes (and are not yet allowed to be
released).
V

···

On Fri, 2005-02-11 at 13:31, Zach Dennis wrote:

Trans wrote:
> Trans wrote:
>
>>>I personally always define them as:
>>>def a?
>>> !!@a
>>>end
>>
>>Nice, thanks.
>
>
> Oops. Except that with Ruby it's not a simple as true and false, there
> is also nil. I think passing nil through unchanged is advantageous as
> it allows for yes, no, maybe (i.e. three state) value.
>

I have failed to see when using three state's is needed. Could you
provide an example where "my_obj.a?" would behave different if nil/false
meant nil/maybe ?

Thanks,

Zach

35

It'd be nice to have an operator like || that only failed for nil - that
way 'false' valued variables wouldn't be splatted by the a ||= b idiom.

martin

···

Zach Dennis <zdennis@mktec.com> wrote:

I have failed to see when using three state's is needed. Could you
provide an example where "my_obj.a?" would behave different if nil/false
meant nil/maybe ?

36

"Trans" <transfire@gmail.com> schrieb im Newsbeitrag
news:1106709424.215471.138980@c13g2000cwb.googlegroups.com...

> Not exactly. But since Ruby can treat any object properly in
> a boolean context, why waste some processing cycles on
> conversion if not because of information hiding (i.e. prevent
> leakage of a member value)?

Well, that wasn't my reasoning when I did it that way. I just thought
it should return boolean (or nil) as one would likely expect from a
?-method. But I see your point too. But perhaps this information hiding
provides it with some merit offsetting the down side of the extra
processing?

Probably. There is also the aspect of resource consumption: if a client
stores a boolean flag which is really a complex object of some type GC
cannot clear it although the owner might have released it already.

> But you didn't have it either and apparently you missed
> it, didn't you? :wink:

:-} He he. I suppose so. Well, it started with the casting and sort of
just grew from there.

As it often does. :slight_smile:

Kind regards

    robert

37

"Martin DeMello" <martindemello@yahoo.com> schrieb im Newsbeitrag
news:At4Qd.388402$6l.353973@pd7tw2no...

>
> I have failed to see when using three state's is needed. Could you
> provide an example where "my_obj.a?" would behave different if

nil/false

> meant nil/maybe ?

It'd be nice to have an operator like || that only failed for nil - that
way 'false' valued variables wouldn't be splatted by the a ||= b idiom.

martin

Isn't #nil? sufficient?

foo = nil

5.times do
  foo.nil? and begin
    foo = false
    puts "changed"
  end
end

Kind regards

    robert

···

Zach Dennis <zdennis@mktec.com> wrote:

38

"Martin DeMello" <martindemello@yahoo.com> schrieb im Newsbeitrag
>
> It'd be nice to have an operator like || that only failed for nil - that
> way 'false' valued variables wouldn't be splatted by the a ||= b idiom.

Isn't #nil? sufficient?

foo = nil

5.times do
  foo.nil? and begin
    foo = false
    puts "changed"
  end
end

That's a lot more verbose, though. And personally, I've only ever used

= for setting uninitialized values, so it'd definitely have been more

useful to have it distinguish between nil and everythingelse. I suppose
this would work:

  class Object
    def splat(other)
      self.nil? ? other : self
    end
  end

  foo = foo.splat 5

but I still like the <operator>= form.

martin

···

Robert Klemme <bob.news@gmx.net> wrote: