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