Performance impact should be fairly small. The code to add the aliases is also written in Java, and only adds aliases for camelCased methods. This means extra AliasMethod objects are created and added to the methods hash, but object creation is pretty lightweight and HashMap is pretty fast. It's also only a one-time hit, so I'd be very surprised if this turned out to be a larger problem.
I personally think the ruby_case makes Java integrated code look a lot nicer, but I am bothered by the namespace pollution and by having two of so many methods. It almost seems that everything should be one way or the other, but I'm not sure which way. Leaving everything camelCase is the most straightforward (and doesn't break any existing code) but it's somewhat jarring to see camelCase next to ruby_case. ruby_case makes the integration of Java code almost invisible, but it either adds a bunch of dupe methods or we break any Java integration code that's using camelCase currently.
On 3/30/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
The two raised questions with the feature so far are:
1. Performance
2. Method namespace pollution
We have largely not decided things from a performance perspective. Since
this landed, I cannot really tell if it is slower or not. I am guessing
if I am having a hard time seeing it, it is not a big issue. In any case,
we have lots of room to speed up java integration in various areas and
I think this will not be a hot spot for a long time.
The namespace pollution seems like more of a concern and I think it would
be nice to be able to toggle this feature on/off. As to a debate whether
it should be on or off by default; I think this will settle itself as a
result of leaving it on by default for a while. We may discover a problem
with it or people will just not notice any issues with it. We are still
developing JRuby and experiments sometimes need to play out like this.
There are some semantics to deal with in regards to toggling this support
on and off. If it is a global setting and you use a third parties library
which depends on loading with ruby_case, but you have it turned off...then
what? Some temporal togglings to make things work again?
Java.ruby_case_feature=true
require 'some_library'
Java.ruby_case_feature=false
We could allow it somehow to include_class itself, but then you would
be forced to do it every time you loaded a class. Just some grist for
the mill.
-Tom
On Thu, 30 Mar 2006, David Corbin defenestrated me:
> On Wednesday 29 March 2006 03:15 pm, Charles O Nutter wrote:
> > I just committed a change to create additional ruby_case aliases for all
> > camelCase Java methods in included classes. For example, an included
> > java.lang.String (as JString) has methods like:
> >
> > sub_sequence
> > compare_to
> > equals_ignore_case
> >
> > We may or may not want to provide a flag to turn this off, since it does
> > add quite a few aliases. I think it looks pretty cool though, and I'd like
> > to have it on by default. How nice is:
> >
>
> What's the performance impact?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jruby-devel mailing list
> Jruby-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
