[ruby-core:17903] Re: duping the NilClass

I believe the current behavior of the dup method is correct given that 
dup returns a new (shallow) copy of the receiver.  The object ID
of that copy must be unique in this definition, otherwise the returned
object is indistinguishble from the receiver. 

Dup raises an exception on immutable contants (like symbols and booleans)
because it cannot return an object having a unique ID that would be
otherwise identical to
the receiver.  (Copy on write would still require unique object IDs. be
generated)

In practice, code often relies on the fact copies can be altered without
affecting the original (receiver) object.  If dup's semantics were modifed
according to this
proposal, such code would likely fail later, often with strange symptoms
that would
likely be much harder to debug, when passed inappropriate operends.  The
current
definition of dup ensures code fails quickly in this case, without
unintended side effects.

I agree that there are times when one would like a "best effort" copy where
self
was returned when no copy can be created.  ":dup!" or ":clone!" seem like
reasonable names for such methods, but I don't feel strongly about this.

- brent


-- 
View this message in context: http://www.nabble.com/-ruby-core%3A17871--duping-the-NilClass-tp18556794p18574770.html
Sent from the ruby-core mailing list archive at Nabble.com.