From: Phrogz <gavin@...>
Date: 2007-02-17T04:15:09+09:00
Subject: Re: Oppinions on RCR for dup on immutable classes

On Feb 16, 11:53 am, dbl...@wobblini.net wrote:
> On Sat, 17 Feb 2007, Phrogz wrote:
> > ...
> > Having said that, I personally would prefer for 3.dup to 'just work',
> > returning an object that is equivalent to the original. Just because
> > the new instance happens to be the same doesn't mean that it's bad -
> > as an immutable object, the only way to tell is via object_id, anyhow.
>
> It doesn't mean it's bad, but it does mean that it isn't a duplicate
> :-)  At least, I wouldn't think that dup is the right name for a
> method that might actually return the receiver.

My perspective is:
If a duplicate of an immutable object is indistinguishable from the
original, then you would have no idea if #dup was returning an
internal duplicate or the same instance. And you wouldn't care (except
that you'd probably prefer it to conserve resources internally and
return the same instance).

The determining question for me, then, is:
How indistinguishable would two distinct instances of these immutable
objects be? The only case where code might break is if you had:
  b = a.dup
  h = { a.object_id => 1, b.object_id=> 2 }
and you were very unhappy if you ended up running over the key. I've
never personally used object_id for that purpose (or any other than
debugging), so I'm not sure how likely that is. I just use objects
themselves as hash keys, in which case equivalent instances already
behave the same (even of mutable objects!):

irb(main):001:0> a = []; b=a.dup
=> []
irb(main):002:0> p a.object_id, b.object_id
23327420
23327410
irb(main):003:0> h = {a=>1, b=>2}
=> {[]=>2}

irb(main):013:0> a,b = 1234567890,1234567890
=> [1234567890, 1234567890]
irb(main):014:0> p a.class, a.object_id, b.class, b.object_id
Bignum
23346300
Bignum
23346270
=> nil
irb(main):015:0> h = {a=>1,b=>2}
=> {1234567890=>2}