This is prone to the same problem that took us away from lazy instantiation in the first place. Namely, if you define a method in Kernel or Object matching the camel case name that you are hoping will be lazily created, then method_missing will not be called.
Perhaps, this is ok for camel case methods? David, you ran into this...Perhaps you can weigh in about likelyhood? If there can be no such sollision, then this solution will not work... -Tom PS- I really like the idea of camel case methods. I do not think I will use them much though. I like to be able to visually tell when I am working with Java classes. I usually encapsulate my Java objects in a Ruby class, since the Java object does not expose the sort of interface I want my ruby app to work with. So the app at large does not see these method names. Just the ruby impl. I will probably try converting one of my scripts over and see how it looks though. On Fri, 31 Mar 2006, David Corbin defenestrated me: > On Thursday 30 March 2006 10:21 pm, Charles O Nutter wrote: > > That's a possibility. > > > > def method_missing(sym, *args) > > camel = to_camel(sym) > > super unless respond_to?(camel) > return super unless respond_to? camel > > send(camel, *args) > > end > > > > I'm sure that's what you meant :) > > > > On 3/30/06, Nick Sieger <[EMAIL PROTECTED]> wrote: > > > On 3/30/06, Charles O Nutter <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > > > A new thought (to me), don't know if this has been mentioned before -- > > > could you add some special logic in a method_missing method somewhere > > > along the method resolution chain that does this lazily, so the methods > > > don't appear there at all? > > > > > > /Nick > > > > -- > > Charles Oliver Nutter @ headius.blogspot.com > > JRuby Developer @ jruby.sourceforge.net > > Application Architect @ www.ventera.com > > > ------------------------------------------------------- > 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
