> To prevent this I think it may be a good idea to define
> to_yaml_properties on ActiveRecord::Base and reject instance variables
> which are association proxies. This could naively be archived by this:
>
> def to_yaml_properties
> instance_variables.reject { |i| instance_variable_get
> (i).r
I realize us Rubyists don't necessarily think the classic works in the
field such as Fowler's "Refactoring" apply to our day-to-day coding in
their entirety but in this case I fully agree with Fowler when he says
"You don't decide to refactor, you refactor because you want to do
something else
The issue that prompted me to revive this is actually related to hash
access. Here's what I was doing:
@clients.group_by {|p| p.name.mb_chars.first }
This gives me back an array that is the same size as the original
@clients array because it sees each Chars string as different.
I unde
Hi Brandon,
The reason I dropped Chars#eql? is because I wanted String#eql? and
Chars#eql? to be symmetric. This can't be done without redefining
String#eql? and I felt at the time that redefining core lib methods
might be a bit much.
I guess if the core team doesn't mind changing String#eql? I
Even if Adam patch make other patches stales, since it cleans up
current ActiveRecord associations code, it wouldn't be hard for others
users to redo their patch. IMHO, it would be even better for people
who are going to make patches in the future.
Rails core guys are obviously very familiar with
On Sat, Mar 7, 2009 at 7:35 PM, Adam wrote:
> More importantly, the added complexity created by importing all of the
> collection logic and interface into a non-collection association class
> just adds to rigidity and potential for odd bugs in the future.
Let's do this refactoring when that actu