On Mon, Sep 21, 2009 at 3:28 PM, Logan Barnett <logus...@gmail.com> 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 not too worried > about changes that aren't backwards compatible. I'm sure this will be > similar for any app that must integrate heavily with Java.
I think this is the most contentious aspect and we are meeting tomorrow face-to-face to try and hammer out what will break and what we can do to mitigate any breakage. Worst-case we just put the contentious stuff into a flag as a way to let people test against what will come in the future (and not release for 1.4). If we do a few things, then things may not cause much/if-any breakage. We need to cover more test cases. If you can give us any test cases which you think this will break it will be helpful in our discussions tomorrow... > Is there a way we can have a smart proxy vs. a dumb proxy? With the talks > I've done people seem mostly interested in how trivial it is to bind to Java > in JRuby. While having to do to_ruby or something similar on any Java proxy > isn't a ton of work, it's no longer as simple as just dropping in the Java > object and running with it. 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 things will work for + out of the box and not break older code. It is possible to load a Java class as smart versus dumb as a solution too. It could work. Is it a good idea? Is it confusing to have different semantics for this mixed together (like two Java object one with dumb and the other smart)? ... -Tom -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
