Simple and stuppid bug (can anyone find it?)

ruby-talk
1

Hi all,
I thought it to be good programming style to make attribute assignment
chainable. When using the attr_writer an assignment returns te value
assigned which is not what I want, so I tried to do-it-myself.
The result is below. This doesn't work. When running Ruby gives:
undefined method 'b=' for "AA":String (NoMethodError)
Anybody, please tell me: *why*. What simple stuppid thing am I
overseeing?
Thanks in advance!
Cheers,
Paul

--the code--
class A
  def initialize
  end
  def a
    return @a
  end
  def a=(someA)
    @a = someA
    return self
  end
  def b
    return @b
  end
  def b=(someB)
    @b = someB
    return self
  end
end

puts A.new.a=("AA").b=("BB").a
--the code--

2

That is explained on page 85 of the Pickaxe (113 in my PDF edition):

   "In older Ruby versions, the result of the assignment was the value
   returned by the attribute-setting method. In Ruby 1.8, the value of
   the assignment is always the value of the parameter; the return
   value of the method is discarded."

-- fxn

···

On Dec 3, 2006, at 11:35 AM, paul wrote:

Hi all,
I thought it to be good programming style to make attribute assignment
chainable. When using the attr_writer an assignment returns te value
assigned which is not what I want, so I tried to do-it-myself.
The result is below. This doesn't work. When running Ruby gives:
undefined method 'b=' for "AA":String (NoMethodError)
Anybody, please tell me: *why*. What simple stuppid thing am I
overseeing?

3

paul wrote:

Hi all,
I thought it to be good programming style to make attribute assignment
chainable. When using the attr_writer an assignment returns te value
assigned which is not what I want, so I tried to do-it-myself.
The result is below. This doesn't work. When running Ruby gives:
undefined method 'b=' for "AA":String (NoMethodError)
Anybody, please tell me: *why*. What simple stuppid thing am I
overseeing?
Thanks in advance!
Cheers,
Paul

--the code--
class A
  def initialize
  end
  def a
    return @a
  end
  def a=(someA)
    @a = someA
    return self
  end
  def b
    return @b
  end
  def b=(someB)
    @b = someB
    return self
  end
end

puts A.new.a=("AA").b=("BB").a
--the code--

There is no bug in your code, apparently Ruby always returns the rvalue
from what parses as an assignment.

With your class loaded into irb, I got:

irb(main):039:0> A.new.a=("AA")
=> "AA"

irb(main):043:0> A.new.send('a=', 'AA') # Does what you expected.
=> #<A:0x3b3015c @a="AA">

So, can anyone recall a rationale for the behaviour (consistency with
mainstream programming languages with regards to assignment?) or is this
a Ruby bug?

Either way, disclaimer: I don't like what you're trying to do in the
first place. Pretty much anyone reading your code will expect assignment
to return the rvalue because that's what #attr_writer does, and the
chained assignment in your example just reads plain ugly to me,
especially since I subconsciously parse it as:
  A.new.a = "AA".b = "BB".a
i.e. ``assign "BB".a to -both- "AA".b and A.new.a''
and therefore am in favour of consistency with assignment in other
languages instead of consistency with Javaesque property setters (where
the ambiguity doesn't manifest.)

David Vallner

4

If you do want to do this, I'd suggest an attr_setter method, that
generates both foo= and set_foo methods. Then you can chain via

a.set_a(100).set_b(10)

which looks much better than the a.a=(100).b=(10)

martin

···

On 12/3/06, paul <pjvleeuwen@gmail.com> wrote:

Hi all,
I thought it to be good programming style to make attribute assignment
chainable. When using the attr_writer an assignment returns te value
assigned which is not what I want, so I tried to do-it-myself.

5

Hi,

···

In message "Re: Simple and stuppid bug (can anyone find it?)" on Sun, 3 Dec 2006 19:53:36 +0900, David Vallner <david@vallner.net> writes:

So, can anyone recall a rationale for the behaviour (consistency with
mainstream programming languages with regards to assignment?) or is this
a Ruby bug?

It's intended behavior. Attribute assignment is assignment (even if
it's implemented by method call). And that's how assignment work for
many languages, including Ruby.

              matz.

6

:slight_smile: thanks all for the educating responses. Martin, I really liked you
suggestion.

Let me explain the reason why I did want to chain assignments:
I have a class that has a lot of attributes that can be written at
creation of an instance. To save my typing the whole lot I made a
constructor getting all those attributes. Though, I expect a lot more
attributes in the near future. Since the attributes are not mandatory
for creating the instance using the constructor-method seemed a little
rigid.
My second idea was to use attr_writer to set all the properties, but
chaining seemed saving me some lines (these assignments aren't that
exciting after all).

Is there any moral/principal reason to write:
  A.a = "AA"
  A.b = "BB"
instead of:
  A.set_b("BB").set_a("AA")

?

Cheers,
Paul

Martin DeMello schreef:

···

On 12/3/06, paul <pjvleeuwen@gmail.com> wrote:
> Hi all,
> I thought it to be good programming style to make attribute assignment
> chainable. When using the attr_writer an assignment returns te value
> assigned which is not what I want, so I tried to do-it-myself.

If you do want to do this, I'd suggest an attr_setter method, that
generates both foo= and set_foo methods. Then you can chain via

a.set_a(100).set_b(10)

which looks much better than the a.a=(100).b=(10)

martin

7

Hi --

:slight_smile: thanks all for the educating responses. Martin, I really liked you
suggestion.

Let me explain the reason why I did want to chain assignments:
I have a class that has a lot of attributes that can be written at
creation of an instance. To save my typing the whole lot I made a
constructor getting all those attributes. Though, I expect a lot more
attributes in the near future. Since the attributes are not mandatory
for creating the instance using the constructor-method seemed a little
rigid.
My second idea was to use attr_writer to set all the properties, but
chaining seemed saving me some lines (these assignments aren't that
exciting after all).

Is there any moral/principal reason to write:
A.a = "AA"
A.b = "BB"
instead of:
A.set_b("BB").set_a("AA")

I guess my question would be: why invent a new way to assign to
instance variables, when Ruby already has a nice way to do that?
Also, I tend to read set_b("BB") as returning "BB". And understanding
it, at the very least, requires knowing about your set_attr method,
which adds another unnecessary layer.

It's not that I think, "Wow, that's elegant!" every time I see an
assignment. They sort of fade into the background. But a new way of
doing them, unless it's really adding value, does draw attention to
itself, largely of a negative kind I would expect.

(I agree with Martin that that's about the best you're going to do if
you feel you have to chain these things, but I'd counsel against the
chaining.)

David

···

On Sun, 3 Dec 2006, paul wrote:

--
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

8

Actually, when I have this problem, I tend to use a third option:

class A
  def initialize(args)
    set args
  end

  def set(arg_hash)
    arg_hash.each_pair {|k, v|
      self.send(:"#{k}=", v)
    }
    self
  end
end

Now you can do a = A.new(:foo => "hello", :bar => "world").whatever
(assuming, of course, that you have appropriately called attr_writer
:foo, :bar or otherwise defined #foo= and #bar= first).

If you only want to set the instance variables when you create the
object, you can get rid of set and inline the code into initialize
instead.

martin

···

On 12/3/06, paul <pjvleeuwen@gmail.com> wrote:

:slight_smile: thanks all for the educating responses. Martin, I really liked you
suggestion.

Is there any moral/principal reason to write:
  A.a = "AA"
  A.b = "BB"
instead of:
  A.set_b("BB").set_a("AA")

9

paul wrote:

My second idea was to use attr_writer to set all the properties, but
chaining seemed saving me some lines (these assignments aren't that
exciting after all).

Either way, I don't agree with the motivation, it's very easy to lose
track of what you've assigned to in a method chain as an extension of
the fact any method chain is a detriment to readability if the steps
aren't trivial (e.g. require keeping in your head what the previous step
returned).

Personally, I'd go with the options hash Martin DeMello proposed. It's
rather idiomatic, easier to read (a bit) than a method chain since
initialisation logic is kept in the call to #new, and doesn't involve
superfluous typing.

David Vallner

10

David Vallner wrote:

paul wrote:

My second idea was to use attr_writer to set all the properties, but
chaining seemed saving me some lines (these assignments aren't that
exciting after all).

Either way, I don't agree with the motivation, it's very easy to lose
track of what you've assigned to in a method chain as an extension of
the fact any method chain is a detriment to readability if the steps
aren't trivial (e.g. require keeping in your head what the previous step
returned).

Personally, I'd go with the options hash Martin DeMello proposed. It's
rather idiomatic, easier to read (a bit) than a method chain since
initialisation logic is kept in the call to #new, and doesn't involve
superfluous typing.

David Vallner

In my opinion, if I understood the problem correctly, if a function/method ends with a 'return self (or whatever)' then that's what should be returned. There is no acceptable excuse for nor returning it.
Cheers, Mike

11

:slight_smile: you would expect it yes :slight_smile: (I did)
Without the help of the guy's here I would have probably taken a while
to figure it out myself.
It's clear for me now. The new rule, written into my brain: methodes
whose names end in '=' always return the first argument. Writing this
down made me think: with multiple arguments, does it return them all,
or just the first. I gave it a try, and it seems like I'm not allowed
to give more then one argument to an methodes whose names end in '='.

Can anyone confirm this as a rule?

irb(main):001:0> class A
irb(main):002:1> def a=(b)
irb(main):003:2> puts 'in a=(b)'
irb(main):004:2> @a = b
irb(main):005:2> return 'c'
irb(main):006:2> end
irb(main):007:1> def a
irb(main):008:2> return a
irb(main):009:2> end
irb(main):010:1> end
=> nil
irb(main):011:0> aa = A.new
=> #<A:0x2c1067c>
irb(main):012:0> aa.a = 'b'
in a=(b)
=> "b"
irb(main):013:0> class X
irb(main):014:1> def x=(y, z)
irb(main):015:2> puts 'in x=(y, z)'
irb(main):016:2> @x = [y, z]
irb(main):017:2> return 'w'
irb(main):018:2> end
irb(main):019:1> def x
irb(main):020:2> return @x
irb(main):021:2> end
irb(main):022:1> end
=> nil
irb(main):023:0> xx = X.new
=> #<X:0x2bfd194>
irb(main):024:0> xx.x=('y', 'z')
SyntaxError: compile error
(irb):24: syntax error
xx.x=('y', 'z')
          ^
        from (irb):24
irb(main):025:0>

12

In my opinion, if I understood the problem correctly, if a
function/method ends with a 'return self (or whatever)' then
that's what
should be returned. There is no acceptable excuse for nor
returning it.

Which is exactly what the method will do... if you call it as a method.
When you call it as an assignment, it returns the assigned value.
Anything else would give rise to confusion of anybody trying to
understand the code when used.

class A
def a=(x)
  @x = x
  return "blah"
end
end

A.new.a='xx'
=> 'xx'
A.new.send(:a=,'xx')
=> 'blah'

It also stops you from shooting yourself in the foot with:

class A
def a=(x)
  @x = x
  recalculate_things
end
end

Which would return the result of recalculate_things... an unexpected
result,
and I'm guessing the motivation behind the change.

Dan.

13

paul wrote:

The new rule, written into my brain: methodes
whose names end in '='

Read: assignments.

always return the first argument.

As assignments do.

Don't think about attribute writes as methods. Don't write them as
methods, it just looks ugly and confuses people, apparently including
you ;:stuck_out_tongue_winking_eye:

Writing this
down made me think: with multiple arguments, does it return them all,
or just the first. I gave it a try, and it seems like I'm not allowed
to give more then one argument to an methodes whose names end in '='.

That's because you're not calling the method per se. You're doing an
attribute write. The Ruby parser reads it as an assignment. The rvalue
isn't even being suspected of being a parenthetised argument list.

In your code, xx.x=('y', 'z') probably gets parsed as:
  xx.x = ('y', 'z'),
where the assignment rvalue ('y', 'z') is invalid Ruby.

You're not allowed to have attribute setters take two parameters,
because it's a syntax feature to set a value to an attribute.

Just as a variable always points to -one- object, an attribute points to
one object as well.

Methods with identifiers ending in = are a special case. They're a
special case for (what I think are) good reasons, and it makes precious
little sense whatsoever to try to use them outside the context of that
special case - such use would be nonidiomatic, and confusing. Most
people reading your code using attribute setters as chained calls would
first cringe, then run it through a code beautifier to at least put a
space around the =, and then visually parse it in the completely wrong
way (as an assignment) if they acted as regular method calls.

Can anyone confirm this as a rule?

[snip code - speaking of which, please indent irb snippets too]

Also:

irb(main):001:0> class Foo
irb(main):002:1> def bar=(baz, bat)

irb(main):003:2> puts "Foo#bar= called with arguments baz=#{baz} and
bat=#{Bat}"
irb(main):004:2> return 'bing'
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0>
irb(main):008:0* foo = Foo.new
=> #<Foo:0x5bf151c>
irb(main):009:0> foo.bar = 1, 2
ArgumentError: wrong number of arguments (1 for 2)
        from (irb):9:in `bar='
        from (irb):9

Multiple items as the rvalue of an assignment expression are always
packed into an array as varargs:

C:\Documents and Settings\David>irb
irb(main):001:0> class Foo
irb(main):002:1> def bar=(baz)
irb(main):003:2> puts "Foo#bar= called with baz=#{baz.inspect}
irb(main):004:2> return :bing
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> Foo.new.bar = 1, 2
Foo#bar= called with baz=[1, 2]
=> [1, 2]

David Vallner

···

from :0