Rick DeNatale wrote:
> On Thu, Jul 30, 2009 at 9:10 PM, David A. Black <dblack / rubypal.com> wrote:
>>
>> My own difficulty with Jeremy's idea is that 1 isn't a duplicate of 1.
>> In general, if x.dup returns x, it's not returning a duplicate of x,
>> so the method name becomes problematic.
> 
> I agree with Jeremy.
> 
> The reason I dup an object is so that if I can change the state of the
> duplicate without affecting the original object.

Agreed.  I don't recall ever having dup'd an object to satisfy
an abstract desire to "create a duplicate".  Rather, I use #dup
as a means to an end, and in my experience it's an end that would
be best served by having immediate objects simply return their
immutable selves.

I'm having trouble even inventing a contrived example where
having #dup succeed for immediates would lead to an undesirable
or unexpected result, in terms of how we would then put the
dup'd values to use.

I don't find it useful to adhere extremely rigidly to the
dictionary definition of the word 'dup', as i don't use #dup for
the end purpose of making duplicates, but to ensure that potential
modifications to the dup'd object won't modify the original.

Having #dup succeed for immediate objects would match my intent,
and if pressed about adherence to the definition of the word 'dup',
I'd want to call this a case of DWIMNWIS.  (Do What I Mean Not What
I Say.)


Regards,

Bill