Attr_*, *variables_*

It wouldn’t be nice if all these methods respect a unique arguments
form. attr_* methods receive a symbol without the @ prefix, but
variables methods receive @ prefixed symbols. Even class_variables
or instance_variables return an array of strings, wouldn’t be better if
they return an array of symbols?

I prefer the attr* notation, but what really matters is to have a unique
invocation form. Does anyone think the same?

Pedro.

P.S - I’ve consulted http://www.ruby-doc.org/core-1.9/index.html for
Ruby 1.9 core reference.

HI –

On Sat, 6 Sep 2008, Pedro S. wrote:

It wouldn’t be nice if all these methods respect a unique arguments
form. attr_* methods receive a symbol without the @ prefix, but
variables methods receive @ prefixed symbols. Even class_variables
or instance_variables return an array of strings, wouldn’t be better if
they return an array of symbols?

I guess so. I don’t really care too much.

I prefer the attr* notation, but what really matters is to have a unique
invocation form. Does anyone think the same?

I’m not sure what problem you’re trying to solve. Why should methods
that manipulate instance variables (@var), class variables (@@var),
and method-name roots (attr_accessor :m) all conform to the same
format, when the identifiers themselves don’t?

David

Hi David,

I’m not sure what problem you’re trying to solve. Why should methods
that manipulate instance variables (@var), class variables (@@var),
and method-name roots (attr_accessor :m) all conform to the same
format, when the identifiers themselves don’t?

Of course this is a minor detail in how methods process their arguments.
What I was trying to say is that when you use for instance
class_variable_set, you know that you’re dealing with class variables so
why it’s necessary to prefix the regular name with @@. The same applies
for instance_variables.

A convention avoids the need to ask yourself if any particular method
has or hasn’t the variable name prefixed by anything. I know that this
is just a small detail but I think that the result with be more
predictable if there’s a convention for kinds of methods.

Pedro.

Pedro S. wrote:

I prefer the attr* notation, but what really matters is to have a unique
invocation form. Does anyone think the same?
(Did you mean ‘uniform’? Or I don’t understand this sentence.)

I agree that it is good to have one standard, but I think that this is
the case here, more or less. And the standard is to give prefixes when
we perform an action on a prefixed variable, and in attr_* arguments are
not prefixed simply because this action (defining accessors) involves
both the variable, and the newly created method, of which the latter is
not prefixed. So they chose that you sort of specify the method name and
not the attribute name.

I agree that writing attr_accessor :@a could be regarded as correct as
well, because this would let anybody use the form they find more
coherent with the rest of the methods, and it would seem more clear to a
beginner (I remember my confusion when I first saw it).

TPR.

Hi –

On Sun, 7 Sep 2008, Thomas B. wrote:

not prefixed. So they chose that you sort of specify the method name and
not the attribute name.

I agree that writing attr_accessor :@a could be regarded as correct as
well, because this would let anybody use the form they find more
coherent with the rest of the methods, and it would seem more clear to a
beginner (I remember my confusion when I first saw it).

attr_accessor :@a is ultimately confusing, though, because the
attribute is not the instance variable itself; it’s implemented with
the instance variable. I know that sounds like splitting hairs, but
it’s important. Attribute is a higher-level concept than instance
variable, and it’s pieced together in Ruby from instance variables and
methods – so :@a would be mixing in an implementation detail (as
would :“a()”, for example, even though it might evoke the
method-creating side of the attr_* family).

David

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs