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
