Meinrad Recheis wrote:
> On Sun, Jul 20, 2008 at 7:55 PM, Urabe Shyouhei <shyouhei / ruby-lang.org
> <mailto:shyouhei / ruby-lang.org>> wrote:
> 
>     Nasir Khan wrote:
>     > While nil is an object, calling dup on it causes TypeError. This
>     doesnt seem
>     > consistent, though a minor kink.
>     > IMHO, ideally duping a nil object should have returned (same) nil.
>     >
> 
>     I don't think so. Nil is _the_ nil, one and only instance of NilClass.
>     Duping it doesn't make sense to me.  And a dup method to return
>     identical object is just strange.
> 
> 
> it makes sense to me, to implement dup on singleton objects like nil to
> implement deep copying of arrays and hashes.
> 
> -- henon

I agree: I end up using "foo.dup rescue foo" in far too many places because
the core singleton and value objects do not return self for dup.  Another
alternative is polluting core classes with:

class Object
  alias :dup_or_self :dup
end
class Numeric
  def dup_or_self; self; end
end
class NullClass
  def dup_or_self; self; end
end
# ... etc


Singletons and value objects are not technically dupable by definition, but
throwing an error is absurd if for most cases #dup are semantically "duplicate
this object to prevent aliases to stateful objects in composition".  Not
having dup return self for immutable objects is far uglier than the workaround
for the actual and common uses of #dup from a functional perspective.

Returning self on immutable #dup does not break anything of value since by
default it never is executed with the current semantics. :)

-- Kurt