Feature #12005
closedUnify Fixnum and Bignum into Integer
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
Updated by nobu (Nobuyoshi Nakada) over 8 years ago
- Description updated (diff)
Could you elaborate the road map?
- move methods from
Fixnum
andBignum
toInteger
, with code to dispatch by its range - deprecate direct use of
Fixnum
andBignum
- 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
andBignum
.
But it is implementation detail.
They should be seen as a single classInteger
likeFlonum
.
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, 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.
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.
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.
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)
Updated by znz (Kazuhiro NISHIYAMA) about 8 years ago
- Related to Feature #12739: deprecate_constant :Fixnum, :Bignum added