On Wed, Oct 7, 2009 at 8:06 PM, Charles Oliver Nutter
<[email protected]> wrote:
> JRUBY-4039 demonstrates a breakage in JRuby where previously a Ruby
> Array used as a List would coerce Fixnum contents only to Long
> objects. In 1.4.0RC1, this broke because of a unification of some
> coercion logic...the merged logic tried to coerce Fixnum to the
> smallest-possible Java numeric type when no target type was specified
> (or when the target type was Object). Because the Array started
> returning Byte for small Fixnums, a List<Long> reference started to
> blow up.
>
> Ignoring the generic stuff for the moment, I have come to the
> conclusion that Fixnums should always coerce to Long unless a specific
> target type is specified. I have made this change for this bug in
> commit 72d49b9 but it required fixing some tests. Specifically, BSF
> and coercion tests that expected the narrower types to be coming out.
>
> My justification is as follows: For a given Fixnum n, calling the same
> method or coercing to an unknown or general type (like Object) should
> produce the same type of object as doing the same operation for n + 1.
> The original behavior that coerced to the narrowest type meant that
> numeric code iterating over a sequence of numbers might return any of
> the numeric Java types, and numeric code counting from 0 to n might
> produce any of those types as well. This is unexpected behavior for
> almost anyone, and making Fixnum always coerce to long/Long resolves
> it.
>
> This change needs to go into 1.4 because it represents a regression.
> I'm writing to get input on whether my logic here is sound, or if
> there's anything I've overlooked. It was not so bad to fix the BSF
> tests, but I had to rewrite an entire example that tested for the
> narrower types.
>
> Input desired :)
I'm satisfied with that explanation. I think the regression is severe
enough to warrant fixing. It's also easier to explain the behavior as
always coercing to Long than to have a Fixnum magically take on the
corresponding size number.
/Nick
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
