On Fri, Aug 7, 2009 at 3:35 AM, Ola Bini<[email protected]> wrote:
> Jimmy Schementi wrote:
>>
>> How about adding NilClass#as(class)? This is much less likely to cause
>> name collisions. We have the same issue with IronRuby, and this is the
>> solution we are favoring currently.
>>
>> obj.doSomething(nil.as <http://nil.as>(Component), 0)

Yeah, I tend to agree with Ola...adding more methods to core classes
is a blunt tool, as clean as it may look. However we do have to_java
already as an "assumed" decoration on core classes. to_* is a more
Ruby-like way to do things, so perhaps we can just do:

nil.to_java(Hashtable)

> I'm still trying to think about how to implement casting in a good way. The
> interesting aspect of casting is that it should only be used when calling
> into Java methods. In my mind that means a cast should be nop if done
> anywhere else. It also shouldn't add methods to objects, so I'm strongly
> against adding an "as" method. Especially since such a method could
> conceivably have a good use in Ruby code.
>
> It's much better to turn it around and let the Java class have the cast
> method, since then it only affects the Java classes.
> So say we have Component.cast(nil). What should it return? A Java proxy of
> some kind that looks like the original object but have a cast-flag. That
> seems expensive.

It would be expensive if we had to construct a new object every time.
But there's only one null...so if every Java class that we import into
Ruby also has a singleton representation of its null self...we've
basically reduced it to method call and possibly constant-lookup
overhead

class Java::JavaLang::String
  def self.null
    @null ||= NullWrapper.new(String)
  end
end
JString = java.lang.String

class NilClass
  def to_java(cls)
    cls.null
  end
end

x.callJava(nil.to_java(JString)) # ruby-style to_*
x.callJava(JString.null) # equivalent behavior with method on the Java class

> I would be much more inclined to add syntax specifically for this - except
> we generally don't like adding syntax at all.

I think if we can mitigate the cost of producing the appropriate null
object, we can avoid the sticky issue of adding syntax. But if we were
to add syntax, what would it look like? No reason we can't brainstorm
a bit...

__cast__(String, nil) # parses as a call to __cast__ but we could make
__cast__ or something similar a keyword.

nil(String) # Does not parse currently since nil is a keyword, so it's
a subtle added syntax

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to