From: Rajinder Yadav Date: 2009-10-20T01:14:57+09:00 Subject: Re: deep cloning, how? On Mon, Oct 19, 2009 at 11:10 AM, Robert Klemme wrote: > On 10/19/2009 10:32 AM, Brian Candler wrote: >> >> Robert Klemme wrote: >>> >>> 2009/10/16 lith : >>>>> >> Taking another example: I don't think you'll disagree that 99% of the time >> you are expected to leave Object.new alone and instead define #initialize in >> your own classes. But you wouldn't find that out from the documentation: >> >> $ ri Object.new >> ------------------------------------------------------------ Object::new >>     Object::new() >> ------------------------------------------------------------------------ >>     Not documented >> >> $ ri Object#initialize >> Nothing known about Object#initialize > > Funny that you mention it: #new and #initialize on one side and #dup / > #clone and #initialize_copy on the other side have one thing in common: > object allocation is separated from initialization.  I believe this was a > wise decision because that way allocation policies can be implemented easier > than in languages like C++ and Java where both are inseparable. > I wonder as I mention already maybe this design has more to do with the fact that Ruby does not perform static type checking like C++ / Java does at compile time. In C++ you just declare a copy constructor (initialize/constructor), if you have other (overloaded) constructor code, then static type checking ensure the correct code logic is executed, thus allowing you to write a cleaner clone method. In Ruby if initialize was called during cloning, you would need to add the logic to perform the dynamic type checking test using Object.class. Who would want to write this boilerplate code over and over? So Ruby's was around this was to use initialize_copy as I am going to assume here. I think cloning in the initializer code would be a better design if Ruby did static type checking. The fact Ruby still does (dynamic) type checking at runtime, means Ruby code gets penalized for performance. It seems the way Ruby does dup/clone/initialize/initialize_copy *throw in subclassing* is a source of confusion for many and not really intuitive, barring good or bad design. The length of this thread and replies would seem to indicate this is a weakness in Ruby design, or I am simply biased with my C++ background? Definitely better updated documentation would help to ensure the correct policy to follow in Ruby. > > Kind regards > >        robert > > -- > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ -- Kind Regards, Rajinder Yadav http://devmentor.org Do Good! ~ Share Freely