On Thu, Jul 30, 2009 at 9:10 PM, David A. Black <dblack / rubypal.com> wrote:
> Hi --
>
> On Fri, 31 Jul 2009, Shyouhei Urabe wrote:
>
>> Issue #1844 has been updated by Shyouhei Urabe.
>>
>>
>> Anyway when getting back to :dup story, I'm not against to make it
>> more "reliable".  ®¬хф фиетуеенфп ве уецетбнеох иете>>
>> * respond_to?(:dup) to be false and calling dup to raise exception.
>> Runpaint's original suggestion.
>> * respond_to?(:dup) to be true and dup to return self. Jeremy's idea.
>
> 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.

Since immediate objects are immutable, I can't change their state so
having dup return the original is not an issue.

Having to code around the possibility that dup will throw an error
seems worse than just having immediates just handle them in what seems
a reasonable fashion.

As a reference point, in Smalltalk the SmallInteger copy method
returns the receiver, this is a direct analogy to Fixnum#dup

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale