From: Jim Weirich <jim.weirich@...>
Date: 2008-07-22T00:03:30+09:00
Subject: [ruby-core:17893] Re: duping the NilClass


On Jul 20, 2008, at 9:59 PM, David A. Black wrote:

> I understand not wanting true.dup etc. to break things, but it's hard
> for me to get past the fact that true.dup doesn't return a dup of
> true, if it's defined to return true. Maybe it's a case for a
> "dangerous" dup:

Funny, I've occasionally come across this need in cases where I was  
dup'ing arbitrary data stored in a container.  Since the data was  
arbitrary (from the dup'ing code's point of view), it could (and  
occasionally did) contain nils, numbers or symbols.  I solved it be  
introducing the following in Kernel:

   def safe_dup
     dup rescue self
   end

So, far from being "dangerous", it was a "safer" version of dup that  
would abort on arbitrary data.

Of course, the problem of adding safe_dup to Kernel from a library is  
that there is the possibility of name clashes where several libraries  
decide to add their own versions of safe_dup.  So I would be in favor  
of adding it as a core library method.

(I would also not oppose a change that "extends" the definition of dup  
to include returning self for immutable objects.  That semantic change  
would have little (or likely no) impact on existing code, with the not  
insignificant advantage that you don't have to worry about catching  
exceptions when dup'ing arbitrary objects.

That's my two cents.

-- 
-- Jim Weirich
-- jim.weirich@gmail.com