-1 for the merge.
+1 for a doc fix where this is more explicit.
I've always used x.becomes(Foo) for the side effect (mutating x)
instead of for the return value.
As I see it, the name _becomes_ clearly states that the receiver is
affected. If it was #convert or #cast or something that would
The reason I disagree with becomes mutating the object in place is because
it's inconsistent with *almost* all of Ruby and Rails' APIs. Methods that
mutate an object (or raise an exception) end with !. Whether it's a string,
hash, or array, methods that mutate these objects have two versions.
Methods that
mutate an object (or raise an exception) end with !.
This isn't correct. dangerous methods end with !. It has nothing to
do with mutation.
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to
I apologize, I wasn't trying to turn this into a debate about semantics. Steve,
does that mean you're in favor of updating the docs too then? If so, any
interest in adding a version that doesn't have side effects?
--
You received this message because you are subscribed to the Google Groups
I don't use this feature, so I don't have an opinion about the
non-side effect version, but I don't see how changing the docs to make
this behavior explicit would hurt anything.
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to
I ran into an interesting issue today with ActiveRecord's becomes method
and discovered that it is mutating the receiver without me knowing it.
The API
docshttp://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-becomessay
The new instance will share a link to the same
On Jul 20, 2012, at 5:48 PM, Peter Brown wrote:
I ran into an interesting issue today with ActiveRecord's becomes method and
discovered that it is mutating the receiver without me knowing it.
The API docs say
The new instance will share a link to the same attributes as the original
Just stumbled upon a pull request from last
yearhttps://github.com/rails/rails/pull/3023with some discussion and it
seemed like people were generally in favor of
changing the behavior. I'd be willing to bring it back to life if people
are still interested in it.
On Friday, July 20, 2012
Got bit by this a couple of weeks ago. +1 for the merge.
Dheeraj Kumar
On Saturday 21 July 2012 at 6:14 AM, Peter Brown wrote:
Just stumbled upon a pull request from last year
(https://github.com/rails/rails/pull/3023) with some discussion and it seemed
like people were generally in
