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

On Tue, Jul 22, 2008 at 12:47 AM, Martin Duerst <[e-mail]>
wrote:

> At 23:51 08/07/21, Urabe Shyouhei wrote:
>
> >FYI, expression "true" refers to the same object on multiple invocations:
> >
> >irb(main):001:0> a = true
> >=> true
> >irb(main):002:0> a.instance_variable_set "@foo", ["bar", "baz"]
> >=> ["bar", "baz"]
> >irb(main):003:0> b = true
> >=> true
> >irb(main):004:0> b.instance_variable_get "@foo"
> >=> ["bar", "baz"]
> >irb(main):005:0>
>
> Is this an actual example shunk down, or is it just made up to
> show a point? If it's the later (as I suspect), then yes, objects
> such as nil and true and false are to a large extent real objects,
> and so can have instance variables and so on.
>

I think that the real distinction in the case of dup between objects like
nil, true, false, symbols and the like is not immutability, but that these
objects are unique.  Unique objects have the property that if two unique
objects are equal they are the same object.

But what we need to show that letting dup return self for true and
> friends is a bad idea is not just that they refer to the same object,
> but that this fact, combined with the usual use of these objects
> (not some bordercase example) creates real problems.
>
> We have already seen three or four people tell us that they
> redefine dup or create another (safer, according to Jim) method.
> We have heard from several people that extending the definition of
> dup wouldn't lead to problems as far as they knew.
>
> We haven't had anybody claim, or show us, that or how extending
> dup semantics would actually cause a problem in real use.
>

Changing dup so that 'duplicating' a unique object returns the same object
is consistent with similar methods in similar/related languages (e.g.
Smalltalk's shallowCopy which is the equivalent of Ruby's dup works this
way).  It feels more natural to me than the status quo since it makes for
less special cases (i.e. exceptions).

The main argument against the change is legacy, that's the way dup has been
defined in Ruby.  The real question is whether the decision to raise an
exception upon the attempt to dup a unique object is more useful than
annoyance.  I suspect that it's the latter, but that's not for me alone to
say.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/