Ruby

I like the idea behind it. \o/

Would probably make more sense too if the defining difference for it
used to be due to performance reasons, as Yui NARUSE wrote.

Yui NARUSE wrote:

CRuby has two Integer classes, Fixnum and Bignum.
But it is implementation detail.
They should be seen as a single class Integer like Flonum.

I like this very much! It always struck me as odd that Integer is special-cased like that. Some implementations have special-cased optimizations for small arrays or hashes (e.g. less than 6 elements), yet they don't have have a separate SmallArray or SmallHash class. Some implementations have special-cased optimizations for small objects (e.g. less than 3 instance variables), yet they don't have a separate SmallObject inheritance hierarchy. YARV has flonums, yet no separate Flonum class. And so on …

The ISO Ruby Language Specification also explicitly treats them as private internal implementation details. It only specifies the Integer class and then allows for "implementation-defined subclasses". (And in fact, I suspect that sentence was only put in there because Fixnum/Bignum already existed when the spec was written.)

Treating it as a private internal implementation detail would also give more freedom to implementors to choose different, more aggressive, or maybe just no optimizations at all. (The latter might be useful for very small implementations intended for embedded use, or very simple implementations intended for educational use.)

I feel that unifying Fixnum and Bignum is simple and beautiful.

However I'm not sure that there are enough concrete benefits over
the incompatibility.

For example, when I made the patch, I need to fix complex.c and
ext/json because they used Fixnum and Bignum class to dispatch.

mathn.rb is another example. mathn.rb modifies methods in Fixnum
and Bignum.
I changed mathn.rb to modify methods in Integer.

Concrete benefits I know is that less code for mathn.rb like library.
It needs to modify only one class, Integer, instead of two, Fixnum and Bignum.

Other benefits?

Are they enough to justify the incompatibility?
I hope enough benefits to justify this issue.

On 2016/05/04 23:54, akr@fsij.org wrote:

I feel that unifying Fixnum and Bignum is simple and beautiful.

However I'm not sure that there are enough concrete benefits over
the incompatibility.

Concrete benefits I know is that less code for mathn.rb like library.
It needs to modify only one class, Integer, instead of two, Fixnum and Bignum.

Other benefits?

Are they enough to justify the incompatibility?
I hope enough benefits to justify this issue.

I think there are some serious benefits in documentation and for
learning Ruby. But these are not so concrete, and more long term.

Regards, Martin.

Akira Tanaka wrote:

Other benefits?

As you show people write Fixnum case and Bignum case.
But sometimes they write only Fixnum even though they must write Bignum case.
Unified Integer avoids such pitfall.

I should have unified those classes at the first hand. It's much cleaner & simpler.
Try unifying them and see if it would go well.

Matz.