From: Mathieu Bouchard Date: 2004-11-28T03:38:04+09:00 Subject: Re: Fixnum#clone and Float#clone raise different exceptions On Sat, 27 Nov 2004, David A. Black wrote: > On Fri, 26 Nov 2004, Yukihiro Matsumoto wrote: > > In message "Re: Fixnum#clone and Float#clone raise different exceptions" > > on Thu, 25 Nov 2004 22:49:20 +0900, Gavin Sinclair writes: > > |4.clone -> 4 sounds better to me, but I must be missing something. > > Do you accept the following behavior? > > a = 4 > > a.instance_eval{@a=5} > > b = a.clone # b = 4 > > b.instance_eval{@a=10} > > a.instance_eval{@a} # @a = 10 > > Similar thing can happen for a Float and singleton methods. > I don't like it -- but even more fundamentally, "clone" really is > never the right name for a method that returns self. A clone is by > definition not the original, however much it may be like the original. Well, it depends what kind of formal definition you give to clone. Pick one: 1) a.clone.id != a.id 2) modifying a.clone does not modify a The latter may be a better working definition, because it extends to non-clonable objects as long as they are non-mutable as well. That is, logically, because a non-mutable object can't be modified, clause #2 is always satisfied by non-mutable objects, even if they work like a.clone.id==a.id. And even if the #1 definition is more obvious (less surprising) than the #2, the #2 is more useful and in practice I don't really see how a programmer could make a mistake with it. (ok, Fixnums are mutable in Ruby, as the above-quoted example shows, but although it's a nice trick to show to your fellow programmers, it's not something that tends to get used by real programs.) _____________________________________________________________________ Mathieu Bouchard -=- Montr�al QC Canada -=- http://artengine.ca/matju