We will brainstorm on this one a bit, but if we can make all Ruby core
types aware of common "it should work" Java types then we may not have
an actual need for explicit coercion. For example, if
RubyFixnum.op_plus(...) accepts a version which works with
java.lang.Number (and subtypes) then thin
[1.9] ARGF improvements to solve several specs
--
Key: JRUBY-3985
URL: http://jira.codehaus.org/browse/JRUBY-3985
Project: JRuby
Issue Type: Improvement
Components: Ruby 1.9
R
Here's a description of the logic as it currently exists.
Java methods are pulled out of java.lang.Class and stuffed into the
proxy class in arity-specific groups. This means when calling with N
arguments, we only look for methods that take N arguments (hence the
missing varargs support).
If you
2009/9/21 Logan Barnett :
> This will prevent Monkeybars apps from upgrading without some big changes.
> Since a Monkeybars app gets its own standalone JRuby, I'm not too worried
> about changes that aren't backwards compatible. I'm sure this will be similar
> for any app that must integrate hea
On Sep 21, 2009, at 9:37 AM, Charles Oliver Nutter wrote:
Types from Java will not auto-coerce
This will prevent Monkeybars apps from upgrading without some big
changes. Since a Monkeybars app gets its own standalone JRuby, I'm not
too worried about changes that aren't backwards compatible.
On Mon, Sep 21, 2009 at 3:28 PM, Logan Barnett wrote:
> On Sep 21, 2009, at 9:37 AM, Charles Oliver Nutter wrote:
>>
>> Types from Java will not auto-coerce
>
> This will prevent Monkeybars apps from upgrading without some big changes.
> Since a Monkeybars app gets its own standalone JRuby, I'm no
[1.9] Array improvements to solve several specs
---
Key: JRUBY-3984
URL: http://jira.codehaus.org/browse/JRUBY-3984
Project: JRuby
Issue Type: Improvement
Components: Ruby 1.9
Nailgun server sometimes refuses to exit or release resources
-
Key: JRUBY-3983
URL: http://jira.codehaus.org/browse/JRUBY-3983
Project: JRuby
Issue Type: Bug
Affects Versions:
Ok, we've been batting this around a bit and I wanted to write up some
doco on it. We're going to try to formalize Java dispatch for 1.4, so
there's an official definition of how it's supposed to work. This
should also finally address problematic dispatch cases like varargs
and numeric overloads.