On Fri, Aug 8, 2008 at 12:59 PM, Charles Oliver Nutter
<[EMAIL PROTECTED]> wrote:
> Charles Oliver Nutter wrote:
>>
>> Thomas E Enebo wrote:
>>>>
>>>> 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.
>
> Actually it seems that the code we have at present *does* append a ? to any
> boolean-returning methods. So for example, in the JI spec fixture
> BeanLikeInterfaceHandler, the boolean friendly() method can be called as
> friendly?. If that feature stays (and it probably should since it was
> shipped with 1.1.3), I think you also should be able to implement friendly?
> for a boolean friendly() interface method. Yes?
Yeah in that case it does seem to make sense...how about modifying
things like so:
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
} ELSE {
7. java name with ? if boolean
8. ruby name with ? if boolean
}
>
>>> 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.
>
> ...
>>
>> 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.
>
> Ok, it also occurred to me why this isn't quite so simple. The lookup done
> for each method needs to be there in the first place because we defer
> creating the Java-based interface impl until the class is first constructed.
> We also don't add the method_added hook until that point, because there's no
> Java class yet for it to update. So at the time the 8x lookup needs to
> happen, it's very possible there's only one of those styles there.
>
> So basically we need to do the search for all 8 styles at least once per
> method. That search could happen at first call, likely never happening again
> since the method_added hook will keep it updated. Or that search could
> happen at class creation time, with up to 8 lookups per each interface
> method being implemented. Either way, you're paying the cost.
>
> One thing I did fix on trunk is that the search wasn't actually ordered 1
> thru 8 because I was stuffing the names into a HashSet during class
> creation. That is now a LinkedHashSet, so the order is predictable.
>
> I'm open for other ideas on the search issue too. But I'm skeptical as to
> whether it's going to be a real hit. It will only ever happen once per
> method per new interface impl class.
Right now in Rails whenever we call a base method we do quite a number
of hash misses and one hash hit. So in many regards we can probably
consider the cost by looking a ruby dispatch cache misses.
-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
