From: dblack@...
Date: 2007-02-17T04:30:59+09:00
Subject: Re: Oppinions on RCR for dup on immutable classes

Hi --

On Sat, 17 Feb 2007, Phrogz wrote:

> 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}

You could conceivably have a case where an object can't be dup'd, but
is mutable, like a singleton class.  If dup returns self, then you
could end up changing the object when you didn't want to.  It's
probably not an everyday problem... but I still don't like the idea of
having to remember that "dup" means "dup or self".


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)