Rails - Jan 2007 - Only one "initialize" method allowed on AR objects?

I''m having some trouble with some seemingly basic OO stuff with one of
my AR::Base descendants.

I ended up creating a custom initialize method that takes two parameters
- an integer and the standard AR attributes hash, like so:

  def initialize(user_id, attributes = nil)

In another part of my application, I was calling "clone" on one of
these
objects and it gave me an incorrect number of arguments error.  I
figured out it was because of the fact that my initialize expects 1
argument no matter what.

As soon as I provided a default value for user_id in the argument list
above, the call to clone was fine - I assume since now my initialization
didn''t require any arguments at all.

But this is somewhat disturbing.  I was under the impression that I
would still have access to the regular initialize(attributes = nil)
method that I get from ActiveRecord::Base.  Why is it not available?

Doesn''t this imply that I can''t have multiple constructors for
an AR
object?

I tried to add

def initialize(attributes = nil)
  super
end

to my object and I still can''t instantiate it just running
"new" (no
arguments).

What gives?

Thanks for any help.

Wes

-- 
Posted via http://www.ruby-forum.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?hl=en
-~----------~----~----~----~------~----~------~--~---

Just a quick glance as I''m out the door, but don''t you mean
this to be a
class method IE self.initialize?
Jason

Wes Gamble wrote:
>
> I''m having some trouble with some seemingly basic OO stuff with
one of
> my AR::Base descendants.
>
> I ended up creating a custom initialize method that takes two parameters
> - an integer and the standard AR attributes hash, like so:
>
>  def initialize(user_id, attributes = nil)
>
> In another part of my application, I was calling "clone" on one
of these
> objects and it gave me an incorrect number of arguments error.  I
> figured out it was because of the fact that my initialize expects 1
> argument no matter what.
>
> As soon as I provided a default value for user_id in the argument list
> above, the call to clone was fine - I assume since now my initialization
> didn''t require any arguments at all.
>
> But this is somewhat disturbing.  I was under the impression that I
> would still have access to the regular initialize(attributes = nil)
> method that I get from ActiveRecord::Base.  Why is it not available?
>
> Doesn''t this imply that I can''t have multiple
constructors for an AR
> object?
>
> I tried to add
>
> def initialize(attributes = nil)
>  super
> end
>
> to my object and I still can''t instantiate it just running
"new" (no
> arguments).
>
> What gives?
>
> Thanks for any help.
>
> Wes
>

--~--~---------~--~----~------------~-------~--~----~
 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?hl=en
-~----------~----~----~----~------~----~------~--~---

Use the :after_initialize callback (or one of the other AR callbacks)
rather than trying to override the initialize method. This is the
recommended Rails approach.

-- 
Posted via http://www.ruby-forum.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?hl=en
-~----------~----~----~----~------~----~------~--~---

Wes Gamble wrote:
> 
> I''m having some trouble with some seemingly basic OO stuff with
one of
> my AR::Base descendants.
> 
> I ended up creating a custom initialize method that takes two parameters
> - an integer and the standard AR attributes hash, like so:
> 
>   def initialize(user_id, attributes = nil)
> 
I think it is generally a bad idea to change the number of arguments for a
method such as initialize. But if you must perhaps,

def initialize(attributes = nil, user_id = nil)
   super  # don''t forget to init in super classes, just in case
   # overwrite init here
   ...
end

might solve some of the problems.
> In another part of my application, I was calling "clone" on one
of these
> objects and it gave me an incorrect number of arguments error.  I
> figured out it was because of the fact that my initialize expects 1
> argument no matter what.
> 
clone by default expects initialize without args, I think.
> As soon as I provided a default value for user_id in the argument list
> above, the call to clone was fine - I assume since now my initialization
> didn''t require any arguments at all.
> 
> But this is somewhat disturbing.  I was under the impression that I
> would still have access to the regular initialize(attributes = nil)
> method that I get from ActiveRecord::Base.  Why is it not available?
> 
Unlike Java, both versions of initialize are the same since Ruby does not
use arguments as part of the method signature.
> Doesn''t this imply that I can''t have multiple
constructors for an AR
> object?
> 
Right. Again unlike Java ...

-- Long
http://MeandmyCity.com/ - Free, searchable business directory for local
communities
http://edgesoft.ca/blog/read/2 - No-Cookie Session Support plugin for Rails


--~--~---------~--~----~------------~-------~--~----~
 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?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks Mick.

I''m aware of the after_initialize method, but I just keep forgetting 
that ActiveRecord objects don''t behave like normal objects.

"Least surprise" my a** :).  Strictly speaking, I suppose, Ruby is 
"least surprise", Rails is "opinionated." :)  But
don''t get me wrong, I
really dig ActiveRecord.

Still, it''s weird to me that the existence of a method (initialize in 
this case) seem to preclude any polymorphism on that method.

Wes


-- 
Posted via http://www.ruby-forum.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?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi --

On Fri, 5 Jan 2007, Wes Gamble wrote:
>
> Thanks Mick.
>
> I''m aware of the after_initialize method, but I just keep
forgetting that
> ActiveRecord objects don''t behave like normal objects.
I don''t think there''s anything in what you''re seeing
that wouldn''t
also be the case of other Ruby objects.  A given object only has one
interpretation of a given message at any given time.  So "initialize"
will always mean "execute the one and only available method on my
radar called ''initialize''".  If you write a new version
that occludes
that method, then the new version will be called.
> "Least surprise" my a** :).  Strictly speaking, I suppose, Ruby
is "least
> surprise", Rails is "opinionated." :)  But don''t
get me wrong, I really dig
> ActiveRecord.
The "Principle of Least Surprise" thing is somewhat deprecated, even
in "just Ruby" circles, because Matz got sick of people citing
violations of it as a way of describing things they didn''t like :-)


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.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?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 4, 2007, at 4:06 PM, Wes Gamble wrote:
>
> Thanks Mick.
>
> I''m aware of the after_initialize method, but I just keep  
> forgetting that ActiveRecord objects don''t behave like normal
objects.
>
> "Least surprise" my a** :).  Strictly speaking, I suppose, Ruby
is
> "least surprise", Rails is "opinionated." :)  But
don''t get me
> wrong, I really dig ActiveRecord.
>
> Still, it''s weird to me that the existence of a method (initialize
> in this case) seem to preclude any polymorphism on that method.
>
> Wes
>

Wes-

	You can define your own initialize methods you just have to make  
sure to call super properly. SInce you are changing the arity of the  
real initialize you need to call super accordingly.

Lets show a simple test

class A
   def initialize(a)
     @a = a
     puts @a
   end
end

class B < A
     def initialize(a=nil,b=nil)
       super(a)
       @b = b
       puts @a
       puts @b
     end
end

 >> A.new ''one''
one
# => #<A:0x30cdfc @a="one">

 >> B.new ''one'', ''two''
one
one
two
# => #<B:0x307884 @a="one", @b="two">


	When you just call super without arguments then it calls the super  
initialize with the same args that were passed to your redefined  
initialize so thats probably why it fails. I''m not sure entirely what  
you need to accomplish but finding the right call to super will  
definitely let you define your own. But AR objects are tricky to deal  
with all the complexity so after_initialize is usually a better choice.


Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez-NLltGlunAUd/unjJdyJNww@public.gmane.org
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



--~--~---------~--~----~------------~-------~--~----~
 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?hl=en
-~----------~----~----~----~------~----~------~--~---

Mick Sharpe wrote:
> Use the :after_initialize callback (or one of the other AR callbacks)
> rather than trying to override the initialize method. This is the
> recommended Rails approach.
You can also use super

  def initialize(foo, *args)
    @foo = foo
    super(*args)
  end

The super method calls the same method as defined in the parent class. 
This let''s you override a method, and still call the original method.

-- 
Posted via http://www.ruby-forum.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?hl=en
-~----------~----~----~----~------~----~------~--~---

Alex Wayne wrote:
> You can also use super
> 
>   def initialize(foo, *args)
>     @foo = foo
>     super(*args)
>   end
> 
This is what I was doing.  If you do this and then attempt to call clone 
on your AR::Base descendant, it will complain.

Wes

-- 
Posted via http://www.ruby-forum.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?hl=en
-~----------~----~----~----~------~----~------~--~---

Wes Gamble <rails-mailing-list@...> writes:
> 
> 
> Alex Wayne wrote:
> > You can also use super
> > 
> >   def initialize(foo, *args)
> >      <at> foo = foo
> >     super(*args)
> >   end
> > 
> 
> This is what I was doing.  If you do this and then attempt to call clone 
> on your AR::Base descendant, it will complain.
> 
> Wes
> 
Have you tried something like

  def initialize(*args)
     <at> foo = args.shift # i.e. remove and use the first item of args
    super(*args)
  end



--~--~---------~--~----~------------~-------~--~----~
 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?hl=en
-~----------~----~----~----~------~----~------~--~---

I now know that there is no method overloading within the context of one 
class due to the dynamic nature of Ruby.  So I get it.

Wes


-- 
Posted via http://www.ruby-forum.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?hl=en
-~----------~----~----~----~------~----~------~--~---