Trans
1/24/2005 7:53:00 PM
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.