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 <[e-mail]> 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饌l QC Canada -=- http://artengine.ca/matju