[ruby-core:39500] Re: [Ruby 1.9 - Feature #5310][Open] Integral objects

On Mon, Sep 12, 2011 at 6:15 PM, Kenta Murata <[e-mail]> wrote:
>
> Issue #5310 has been reported by Kenta Murata.
>
> ----------------------------------------
> Feature #5310: Integral objects
> http://redmine.ruby-lang.org/issues/5310
>
> Author: Kenta Murata
> Status: Open
> Priority: Normal
> Assignee:
> Category: core
> Target version: 1.9.x
>
>
> I believe it is ambiguous what object can behave as an integral number.
> I don't think the current use of Object#to_int isn't appropriate for this purpose.
>
> The most understandable example is Float#to_int.
> It should raise error for all float values because they always have uncertainty,
> but it doesn't and returns an integral part of it.
>
> I propose to change the use of Object#to_int for the next release of Ruby.
> I recommend the following specification changes:
>
> (1) Remove to_int method from Float and BigDecimal.
> (2) Rational#to_int returns an Integer only if its denominator is 1. Otherwise, it raises an appropriate error.
> (3) Complex#to_int returns the result of to_int of its real part only if its imaginary part is exactly zero (0.0 isn't exactly zero).
>
> If anyone have another idea, please give me your comment.

I strongly disagree with this proposal.

Any object should be allowed to participate in integral operations
based on the object's implementing #to_int. When object A requests
that object B represent itself as an integral value, it is up to
object B to do so, or not do so. The only thing that object A should
require is that the value returned from #to_int be an integral value.
The object A should have no say is how the object B represents itself.
To do so is to 1) severely break encapsulation; 2) impose ad hoc
type/class requirements that break ducktyping; 3) create more brittle,
non-OO code.

Should it not be clear, allow me to reiterate that I am adamantly
opposed to this change.

Cheers,
Brian

>
>
> --
> http://redmine.ruby-lang.org
>
>