Re: Proposal: New Bignum

Hm. Seems like this might be a bit too magical, but it would work. Perhaps
use method_missing on Fixnum to catch and test method existence against
MBignum. I worry about what kind of performance hit this would incur though,
if ended up happening over and over again.

Here's a thought: We need to balance speed, usage, and ease. The current
model does that via autoconversion and having the methods of Bignum match
those of Fixnum exactly. If MBignum replaces Bignum and thus adds methods
that are not present in Fixnum, we can solve the problem using Dave's idea.
This provides the same environment that is currently present. And then we
add another feature for people like me, that it certain sections don't want
autoconversion because I know I want Bignum's. We could implement
Numeric#preserve, which would set a flag to tell Fixnum and Bignum to not
autoconvert. Here's a code example:

m.class # Bignum
n.class # Bignum
i = m - n # 1
i.class # Fixnum

Numeric.preserve {
	i = m - n # 1
	i.class   # Bignum
}

This allows MBignum to replace Bignum without changing any existing
behavior, and allows developers that know which type they'd like to work
with that type without interference from autoconversion.

Evan

> -----Original Message-----
> From: Dave Thomas [mailto:[e-mail]]
> Sent: Tuesday, April 06, 2004 11:21 AM
> To: [e-mail]
> Subject: Re: Proposal: New Bignum
> 
> 
> On Apr 6, 2004, at 12:58, Evan Webb wrote:
> 
> > My suggestion is that we use the preserve-type model wherever
> > possible, but
> > it is most likely what the programmer is expecting.
> 
> An alternative, which is more compatible with the existing scheme,
> would be to have MBignum - MBignum potentially return a Fixnum, but
> then have Fixnum handle undefined methods that _are_ defined by bignum
> by converting self to a MBignum and then re-dispatching the message, so
> 
>     2.exptmode(e,p)
> 
> would always work (by converting '2' to a MBignum and then using
> MBignum's method)
> 
> 
> > Cheers
> 
> Dave
>