Re: Fixnum#clone and Float#clone raise different exceptions

Hi --

On Sat, 27 Nov 2004, Mauricio Fern疣dez wrote:

> On Fri, Nov 26, 2004 at 10:17:57AM +0900, Florian Gro゜ wrote:
> > >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 think this is okay. I think getting an exception when doing obj.clone 
> > is a thing that would be against expected behavior more frequently than 
> > sharing instance variables on immediate Objects. (Instance variables on 
> > those are not used frequently anyway.)
> 
> Why is the attached patch unacceptable? I can see two problems, but
> I'm not sure they justify discarding this option:
> * conceptually, Float objects are immutable so it'd make sense to have only
>   one for a given value. However, they are not truly immediate, and in the
>   current implementation there can be several Float objects with the
>   same value.

That probably has a bearing on my earlier claim, too -- namely, that
Floats shouldn't claim to clone themselves.  Maybe they should, since
the new object would be a different object.  


David

-- 
David A. Black
[e-mail]