From: Trans <transfire@...>
Date: 2005-01-25T04:55:52+09:00
Subject: Re: attr


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

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