On Fri, Aug 8, 2008 at 4:06 AM, Charles Oliver Nutter
<[EMAIL PROTECTED]> wrote:
> I've added a couple enhancements over the past few weeks I figured I should
> list here for discussion.
>
> 0. Obviously, there's been a lot of performance work.
>
> 1. Closures can be passed to any method with an interface as its last
> argument; the closure will be converted to the target interface type.
>
> thread = java.lang.Thread.new { puts 'here' }
>
> 2. Interfaces can be implemented using Ruby-cased (underscored) names for
> all methods now.
>
> class Foo
> include java.awt.event.ActionListener
> def action_performed(event)
> ...
> end
> end
>
> 3. Interfaces with bean-like methods can be implemented using attr*.
>
> Java:
> public interface Blah {
> public Object getMyX();
> public void setMyX(Object x);
>
> public boolean isMyY();
> public void setMyY();
>
> public boolean yumYum();
> }
>
> Ruby:
> class Foo
> include Blah
> attr_accessor :my_x
> attr_accessor :my_y
> # attr_accessor :myX or :myY also work
> end
>
> Of course this implies you can also def my_x=(i) just the same.
>
> 4. Interfaces with boolean methods can be implemented using the
> question-marked version of the method name.
>
> class Foo
> include Blah
> def isMyY?; end # works
> def is_my_y?; end # works
> def myY?; end # works
> def my_y?; end # works
> def yum_yum?; end # works
> def yumYum?; end # works
>
> *** NOTE ***
>
> This extensive support of Ruby naming may be going too far. I'm really
> looking for opinions on this, to see whether it's too much. In general my
> primary goal was to allow users to use either straight-up Java names or
> various gradations of Ruby names, all the way to the most Ruby-like = or ?
> underscored names. So those extreme cases work and all intermediate cases
> work. But is it excessive?
>
> Also, it's currently rather undefined what happens if you're mixing forms.
> It currently will search for methods in this order if they haven't been
> found previously:
>
> 1. normal Java name
> 2. ruby name with underscores
> IF PROPERTY {
> 3. java property name (minus get/set/is)
> 4. java property name with ? if boolean
> 5. ruby property name (java prop name with underscores)
> 6. ruby property name with ? if boolean
> }
> 7. java name with ? if boolean
> 8. ruby name with ? if boolean
7 and 8 do not seem right to me...
> Now there's two implications here.
>
> First, defining as two different forms will have unusual effects, since
> redefining a method will try to update what the Java interface dispatches
> to. So you could have two different forms with different bodies, but only
> the last one wins.
>
> Second, for cases where you want to use method_missing to handle all calls
> through that interface, there's going to be up to 8 times as many method
> table searches before falling back on method_missing. This may impact
> performance of "anonymous interfaces" like the converted closures above,
> albeit by an unknown amount (benchmarking help for all this is requested :)
removing 7 and 8 will make that up to 6 times. It is up to 4 if
!boolean. Up to 2 if not a property. It seems like 4x will be most
common. Putting commonest calling convention in front will reduce
what it generally is.
I keep thinking there is a more complex way of doing this which will
end up being a single search. Like canonicalizing method name then
doing a single lookup.
> So I think we should try to talk through some of this stuff.
-Tom
--
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
