Rails - Oct 2006 - belongs_to nonintuitive results with assignment?

class Page < ActiveRecord::Base
    has_many :lists
end

class List < ActiveRecord::Base
    belongs_to :page
end

######### controller code, inside action:
    list = List.find(params[:id])
    old_page = list.page
    list.page = new_page
    # what is the value of old_page now?

old_page now is the same as new_page!   what the heck?!?

The only thing i can think of is that old_page is getting assigned some
kind of proxy object, rather than the Page object itself, and
"list.page = new_page" changes only the actual Page object pointed to
by the (same) proxy object.  Am I on the right track?

The workaround is easy, of course.  But would it really be that hard to
maintain normal object referencing behavior?

Not sure if I''m asking a question or just ranting.  But if other people
don''t see this behavior, or if there''s an elegant explanation
of why it
has to be this way, then I''d like to know.

-Brian


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi --

On Mon, 30 Oct 2006, brian.estlin wrote:
>
> class Page < ActiveRecord::Base
>    has_many :lists
> end
>
> class List < ActiveRecord::Base
>    belongs_to :page
> end
>
> ######### controller code, inside action:
>    list = List.find(params[:id])
>    old_page = list.page
>    list.page = new_page
>    # what is the value of old_page now?
>
> old_page now is the same as new_page!   what the heck?!?
>
> The only thing i can think of is that old_page is getting assigned some
> kind of proxy object, rather than the Page object itself, and
> "list.page = new_page" changes only the actual Page object
pointed to
> by the (same) proxy object.  Am I on the right track?
>
> The workaround is easy, of course.  But would it really be that hard to
> maintain normal object referencing behavior?
>
> Not sure if I''m asking a question or just ranting.  But if other
people
> don''t see this behavior, or if there''s an elegant
explanation of why it
> has to be this way, then I''d like to know.
I do see it, though I''d never noticed it before.  I have no idea what
the rationale for it is.


David

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I got bit by this too, but on reflection (no pun intended ;) it is correct, I
was actually doing it
the other way around and assigning the has_many, but it is the same issue.

Just think of it as pointer assignment if you come from c/c++.

One work around in your case is to do this instead...

old_page_id= list.page.id

I did this as it was an array...

old_lists= page.lists.clone

that way I got a clone of the array of lists, not a pointer to the lists
has_many proxy. (or
whatever it is).

brian.estlin wrote:
> class Page < ActiveRecord::Base
>     has_many :lists
> end
> 
> class List < ActiveRecord::Base
>     belongs_to :page
> end
> 
> ######### controller code, inside action:
>     list = List.find(params[:id])
>     old_page = list.page
>     list.page = new_page
>     # what is the value of old_page now?
> 
> old_page now is the same as new_page!   what the heck?!?
> 
> The only thing i can think of is that old_page is getting assigned some
> kind of proxy object, rather than the Page object itself, and
> "list.page = new_page" changes only the actual Page object
pointed to
> by the (same) proxy object.  Am I on the right track?
> 
> The workaround is easy, of course.  But would it really be that hard to
> maintain normal object referencing behavior?
> 
> Not sure if I''m asking a question or just ranting.  But if other
people
> don''t see this behavior, or if there''s an elegant
explanation of why it
> has to be this way, then I''d like to know.
> 
> -Brian
> 

-- 
Jim Morris, http://blog.wolfman.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi --

On Mon, 30 Oct 2006, Jim Morris wrote:
> brian.estlin wrote:
>> class Page < ActiveRecord::Base
>>     has_many :lists
>> end
>>
>> class List < ActiveRecord::Base
>>     belongs_to :page
>> end
>>
>> ######### controller code, inside action:
>>     list = List.find(params[:id])
>>     old_page = list.page
>>     list.page = new_page
>>     # what is the value of old_page now?
>>
>> old_page now is the same as new_page!   what the heck?!?
>>
>> The only thing i can think of is that old_page is getting assigned some
>> kind of proxy object, rather than the Page object itself, and
>> "list.page = new_page" changes only the actual Page object
pointed to
>> by the (same) proxy object.  Am I on the right track?
>>
>> The workaround is easy, of course.  But would it really be that hard to
>> maintain normal object referencing behavior?
>>
>> Not sure if I''m asking a question or just ranting.  But if
other people
>> don''t see this behavior, or if there''s an elegant
explanation of why it
>> has to be this way, then I''d like to know.
>
> I got bit by this too, but on reflection (no pun intended ;) it is
> correct, I was actually doing it the other way around and assigning
> the has_many, but it is the same issue.
>
> Just think of it as pointer assignment if you come from c/c++.
I come from Ruby :-)  It seems very odd to me.
> One work around in your case is to do this instead...
>
> old_page_id= list.page.id
Hey, enjoy the syntactic sugar:

   old_page_id = list.page.id

:-)
> I did this as it was an array...
>
> old_lists= page.lists.clone
>
> that way I got a clone of the array of lists, not a pointer to the
> lists has_many proxy. (or whatever it is).
This makes for the (to me) strange situation where:

   a = list.page
   b = Page.find(a.id)

lead to two different behaviors in the face of changing list.page.
I''m not seeing what the purpose or advantage of this is.


David

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org wrote:
>> Just think of it as pointer assignment if you come from c/c++.
> 
> I come from Ruby :-)  It seems very odd to me.
> 
>> One work around in your case is to do this instead...
>>
>> old_page_id= list.page.id
> 
> Hey, enjoy the syntactic sugar:
> 
>    old_page_id = list.page.id
> 
> :-)
> 
>> I did this as it was an array...
>>
>> old_lists= page.lists.clone
>>
>> that way I got a clone of the array of lists, not a pointer to the
>> lists has_many proxy. (or whatever it is).
> 
> This makes for the (to me) strange situation where:
> 
>    a = list.page
>    b = Page.find(a.id)
> 
> lead to two different behaviors in the face of changing list.page.
> I''m not seeing what the purpose or advantage of this is.
> 
Agreed it threw me, but I gave up worrying about the why''s a long time
ago, I''m just thankful I got
around the problem without spending hours on it ;) As a sage once said "I
am''s What I am''s", or in
this case "it is as it is".




-- 
Jim Morris, http://blog.wolfman.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Well, I''m not going to spend too much time worrying about it either.
But here''s the thing that IMO makes it a bad design.  If I show you the
following code:

old_page = list.page
list.page = new_page
# what is the value of old_page now?

your answer (as to what old_page is) will be *different* depending on
whether "list.page" represents an ActiveRecord association or not.
I.e., you can''t tell, just by looking at the above code.  You have to
go track down what "list" is and look in it''s class
definition to see
whether "page" is an association.

Of course, in a small single-developer application, which mine is, it''s
not really an issue.  But if you''re handing a 50,000-line codebase to
another developer, it''s kind of unfortunate.  So IMO it''s a
code
readability/maintainability turkey.

In C pointer assignment, you at least can make a good guess from all
the little *''s what''s actually going on.  ;-)

-Brian


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

brian.estlin wrote:
> Well, I''m not going to spend too much time worrying about it
either.
> But here''s the thing that IMO makes it a bad design.  If I show
you the
> following code:
> 
> old_page = list.page
> list.page = new_page
> # what is the value of old_page now?
> 
> your answer (as to what old_page is) will be *different* depending on
> whether "list.page" represents an ActiveRecord association or
not.
> I.e., you can''t tell, just by looking at the above code.  You have
to
> go track down what "list" is and look in it''s class
definition to see
> whether "page" is an association.
> 
> Of course, in a small single-developer application, which mine is,
it''s
> not really an issue.  But if you''re handing a 50,000-line codebase
to
> another developer, it''s kind of unfortunate.  So IMO it''s
a code
> readability/maintainability turkey.
> 
> In C pointer assignment, you at least can make a good guess from all
> the little *''s what''s actually going on.  ;-)
> 
> -Brian
> 
I fully agree, it is non-intuitive and very confusing, I wonder what it would
take to fix it,
without breaking a bunch of other stuff?

-- 
Jim Morris, http://blog.wolfman.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi --

On Tue, 31 Oct 2006, Jim Morris wrote:
>
> brian.estlin wrote:
>> Well, I''m not going to spend too much time worrying about it
either.
>> But here''s the thing that IMO makes it a bad design.  If I
show you the
>> following code:
>>
>> old_page = list.page
>> list.page = new_page
>> # what is the value of old_page now?
>>
>> your answer (as to what old_page is) will be *different* depending on
>> whether "list.page" represents an ActiveRecord association or
not.
>> I.e., you can''t tell, just by looking at the above code.  You
have to
>> go track down what "list" is and look in it''s class
definition to see
>> whether "page" is an association.
>>
>> Of course, in a small single-developer application, which mine is,
it''s
>> not really an issue.  But if you''re handing a 50,000-line
codebase to
>> another developer, it''s kind of unfortunate.  So IMO
it''s a code
>> readability/maintainability turkey.
>>
>> In C pointer assignment, you at least can make a good guess from all
>> the little *''s what''s actually going on.  ;-)
>>
>> -Brian
>>
>
> I fully agree, it is non-intuitive and very confusing, I wonder what it
would take to fix it,
> without breaking a bunch of other stuff?
I''d argue that if this were gotten rid of, any changes that had to be
made to things that depended on it would be by way of *fixing* those
things :-)

Disclaimer: I''m still open to hearing a rationale for it from the
team.


David

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---