On Mon, Aug 10, 2009 at 11:10 AM, Logan Barnett<[email protected]> wrote: > Is the problem here that you can't cast to null with the correct type, or > you just can't invoke the correct override? I'm thinking it's override > selection. > > All of the null casting suggestions seem great if you know that you have > nil, but typically we have a variable which may or may not be nil. If we > allow a method that lets us specify which types to use, would that be enough > to resolve the proper override?
Yeah this was one thing which also bothered me about all of our suggestions. For the most part this is largely only a problem with it is nil, but then again our matching logic is not quite JLS-compatible (Java Language Specification) so I am sure there are a few stray cases where we want to be more specific about how we match to a particular signature. The one other case I know we have is the int, long matching problem and the current solution is to box the value in a Java wrapper type. This possibly is improved by your recommendation since it allows us to pass the raw value in without boxing... -Tom > > foo = nil > bar = 5 > obj.java_send([:Component, :int], foo, bar) > obj.java_send([:Frame, :int], foo, bar) > > Maybe java_send only lives on Java proxy objects (or Ruby objects that have > a parent Java class). This way you don't muck with core stuff. > > > Logan Barnett > [email protected] > http://www.logustus.com > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: [email protected] --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
