From: Gregory Brown <gregory.t.brown@...>
Date: 2007-02-17T08:47:06+09:00
Subject: Re: Oppinions on RCR for dup on immutable classes

On 2/16/07, Phrogz <gavin@refinery.com> wrote:
> On Feb 16, 3:28 pm, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
> > On 2/16/07, Robert Dober <robert.do...@gmail.com> wrote:
> >
> > > On 2/16/07, Phrogz <g...@refinery.com> wrote:
> > > > b) You should never ever write "a.dup rescue a" because it will give
> > > > you strange problems if a might refer to a mutable object that doesn't
> > > > respond to #dup.
> > > Neve say never ;) but when you write
> > > a.dup rescue a
> > > you should be aware of that potential danger
> >
> > Right.  My only point was that this solved what the OP asked for
> > without being hard.
> > It just seems like that solution is no better or worse than changing
> > the behaviour of dup, except for the fact that it puts the burden of
> > bad design into the programmer's hands, and not that of the
> > programming language :)
>
> IF the proposed implementation were to do what you suggested - rescue
> every dup error by returning self - then I would agree that it's a bad
> design feature to put into the language.
>
> I personally believe that returning self for symbols, fixnums, true,
> false, and nil is not bad or dangerous in any way. Can you provide a
> single example (even if contrived) where this could produce an
> unintended result? I can only come up with one myself, and it's too
> contrived for me to consider it a danger.

the only things I can think of involve singleton methods

>> def nil.foo
>>   "hi there"
>> end
=> nil
>> nil.foo
=> "hi there"
>> b = nil.dup
TypeError: can't dup NilClass
        from (irb):13:in `dup'
        from (irb):13
>> def b.bar; "confusing?"; end

Imagine no error was thrown by that dup.

bar would be defined both on the duped (really not duped at all) nil
in your b variable, and on nil itself.

This of course is contrived, but it would be surprising behaviour.  (I think)