Thomas E Enebo wrote:
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...
So I think in misinterpreted some code added in the last release to
support ? forms of properties. The code appeared to try to add such
names for all boolean methods, but I believe the intention was to only
add it for property names. I'm going to boot 7 and 8.
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.
I suppose that's possible. Currently the interface impl stuff works like
this (and this design is largely why it's going to be faster than in 1.1.4):
1. The Java implementation class has a number of static fields that hold
references to the associated Ruby class, the runtime which created the
class, and also a field for each method being implemented.
2. When first calling any of those methods from Java, it will check to
see if the field associated with the method is non-null. If it's null,
it will search for the method using the rules above and populate the field.
3. For methods that change after they've been called, a method_added
hook is provided for the class that resets the associated field to the
new method.
This essentially eliminates dynamic dispatch entirely when calling into
Ruby through a Java interface. But there's that initial hit to look up
the methods. Now we could actively search for those methods when the
class is created and pre-populate the fields, but I'm not doing that
right now.
In order to do what you're saying, we would want to search only for the
canonicalized name, and for all method_added always update that
canonicalized name. For example, the canon name could be the original
Java method name; so when you define my_foo= it would also redefine
setMyFoo.
Hmm...that could work. Anyone see any problem with doing that besides
the side effect that mixing naming styles would always overwrite the
canonical Java name?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
