Gregory Brown wrote:
> On 2/16/07, Stefan Rusterholz <apeiros / gmx.net> wrote:
>> > |
>> That's why I have 2 suggestions. The issue arises when you don't know
>> those classes can't really be duped (ie. return self) or expose that
>> transparently (not implement dup).
> 
>>> a = 3
> => 3
>>> b = a.dup rescue a
> => 3
>>> b
> => 3
> 
> What's so bad about that?

As I said, I consider it a minor glitch. Of course you can work around 
the problem, but a workaround is still only a workaround. IMHO the 
"correct" way to do what you do above would be:

b = a.respond_to?(:dup) ? a.dup : a

If you have concerns about that beeing not as fast as rescuing your code 
would still work (the raised exception would just be different).
Since that is my oppinion I posted this to the ML to see what other 
oppinions about that are.
Besides, your above code assumes that the only reason a dup fails is due 
to the singleton-immutables, what if dup fails due to another reason? 
With your above code you'll have a happy time tracking the bug as a 
potential exception will never be raised.

My regards

-- 
Posted via http://www.ruby-forum.com/.