Project

General

Profile

Actions

Feature #12005

closed

Unify Fixnum and Bignum into Integer

Added by naruse (Yui NARUSE) over 8 years ago. Updated over 8 years ago.

Status:
Closed
Target version:
-
[ruby-core:72918]

Description

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

Compatibility note

  • Q: How do I check whether Fixnum and Bignum are unified or not?
  • A: check RUBY_INTEGER_UNIFICATION macro

Files

unify-fixnum-and-bignum.patch (30.5 KB) unify-fixnum-and-bignum.patch akr (Akira Tanaka), 05/03/2016 10:18 AM

Related issues 2 (0 open2 closed)

Related to Ruby master - Bug #12427: Defining methods with the same name to both Fixnum and Bignum classes could cause SEGV in C extensions since Feature #12005ClosedActions
Related to Ruby master - Feature #12739: deprecate_constant :Fixnum, :BignumClosedActions

Updated by nobu (Nobuyoshi Nakada) over 8 years ago

  • Description updated (diff)

Could you elaborate the road map?

  1. move methods from Fixnum and Bignum to Integer, with code to dispatch by its range
  2. deprecate direct use of Fixnum and Bignum
  3. remove them

Please correct it if something is missing.

Updated by shevegen (Robert A. Heiler) over 8 years ago

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.

Updated by jwmittag (Jörg W Mittag) over 8 years ago

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.)

Updated by shyouhei (Shyouhei Urabe) over 8 years ago

  • Status changed from Open to Assigned
  • Assignee set to mrkn (Kenta Murata)

Updated by akr (Akira Tanaka) over 8 years ago

I made a patch to unify Fixnum and Bignum:
unify-fixnum-and-bignum.patch

For rough compatibility, I defined Fixnum and Bignum as Integer.
So, foo.kind_of?(Fixnum) works as foo.kind_of?(Integer).
This works mostly because most application doesn't have interest
on the boundary between Fixnum and Bignum which vary on platforms.

Updated by akr (Akira Tanaka) over 8 years ago

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.

Updated by duerst (Martin Dürst) over 8 years ago

On 2016/05/04 23:54, 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.

Updated by naruse (Yui NARUSE) over 8 years ago

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.

Updated by matz (Yukihiro Matsumoto) over 8 years ago

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.

Actions #10

Updated by akr (Akira Tanaka) over 8 years ago

  • Status changed from Assigned to Closed

Applied in changeset r55024.


[Feature #12005] Unify Fixnum and Bignum into Integer

  • [Feature #12005] Unify Fixnum and Bignum into Integer

  • include/ruby/ruby.h (rb_class_of): Return rb_cInteger for fixnums.

  • insns.def (INTEGER_REDEFINED_OP_FLAG): Unified from
    FIXNUM_REDEFINED_OP_FLAG and BIGNUM_REDEFINED_OP_FLAG.

  • vm_core.h: Ditto.

  • vm_insnhelper.c (opt_eq_func): Use INTEGER_REDEFINED_OP_FLAG instead
    of FIXNUM_REDEFINED_OP_FLAG.

  • vm.c (vm_redefinition_check_flag): Use rb_cInteger instead of
    rb_cFixnum and rb_cBignum.
    (C): Use Integer instead of Fixnum and Bignum.

  • numeric.c (fix_succ): Removed.
    (Init_Numeric): Define Fixnum as Integer.

  • bignum.c (bignew): Use rb_cInteger instead of Rb_cBignum.
    (rb_int_coerce): replaced from rb_big_coerce and return fixnums
    as-is.
    (Init_Bignum): Define Bignum as Integer.
    Don't define ===.

  • error.c (builtin_class_name): Return "Integer" for fixnums.

  • sprintf.c (ruby__sfvextra): Use rb_cInteger instead of rb_cFixnum.

  • ext/-test-/testutil: New directory to test.
    Currently it provides utilities for fixnum and bignum.

  • ext/json/generator/generator.c: Define mInteger_to_json.

  • lib/mathn.rb (Fixnum#/): Redefinition removed.

Actions #11

Updated by naruse (Yui NARUSE) over 8 years ago

  • Related to Bug #12427: Defining methods with the same name to both Fixnum and Bignum classes could cause SEGV in C extensions since Feature #12005 added

Updated by naruse (Yui NARUSE) over 8 years ago

  • Description updated (diff)
Actions #13

Updated by znz (Kazuhiro NISHIYAMA) about 8 years ago

  • Related to Feature #12739: deprecate_constant :Fixnum, :Bignum added
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0