There's a standing question whether the parentModule should be maintained in RubyModule. So far, eliminating it does not appear to have broken anything, but I see where it could become confused. parentModule was used incorrectly for finding constants, but it was perhaps correctly used for Module#getName and Module.nesting. Both of those, however, still appear to be working correctly in JRuby. There's also a question as to what cref should be after multiple re-openings of the same class def. However, as with parentModule, I believe cref ends up being set the first time the class is instantiated, making that its "default" cref. Methods defined in those later openings, however, will use a somewhat different cref, as would be expected.
So we won't land this patch quite yet, but I'll be investigating these issues and trying to find some test cases that cause the new patch to produce incorrect results. And hey, more test cases is always good, right? - Charlie On 1/29/06, Charles O Nutter <[EMAIL PROTECTED]> wrote: > Whew, this was a big'un. > > This takes Tom's CRef work and does the following: > > - Gets all evals working correctly with cref (at least as correctly as > necessary to make ant test, rubicon, rubygems, and rails work as well > as before). No test case created, but a number of our existing cases > failed before this fix. > - Replaces all parentModule stuff in RubyModules with the cref code, > to allow evaling against a class in the appropriate context. There may > be further optimizations possible since the original code assumed the > cref tree would exist outside the RubyModule classes, while this one > has it intermingled and available more easily. Some of our old > parentModules may have been incorrect; I have only repaired those > where they caused new failures with CRef. There will need to be more > examination of what the appropriate nesting is for, say, singleton > classes, metaclasses, and so on that are not created inside an > explicit nesting. Test cases created only for cases that I broke along > the way (and had to fix). > - Fixes calls to "super" inside module methods. Modules were being set > up with an implicit superclass of Object instead of Module, so > overriding something like extend_object and calling super started > failing once the cref fix was in. Test case created. > - Adds a dummy "syck.rb" under src/lib/ruby/1.8/yaml for programs like > RubyGems that explicitly require 'yaml/syck'. No test case created. > - Completes handling of ConstDeclNode and defined? <constant> > appropriate for CRefs. defined? (in DefinedVisitor) is less than ideal > in that it currently catches the const_missing error. No test case > created. > - Fixes creation of "virtual" superclasses for included modules. Where > before it added them in reverse hierarchical order (resulting in > ancestors coming before descendants in the new "virtual" hierarchy) it > now adds them in the correct order (matching that of the incoming > module). No test case created. > - Fixed "retry" loop in getConstantInner (from C ruby's > rb_const_get_0). It didn't quite match the C code since there's no > "goto" in Java. More work is needed there, obviously, to add autoload > capability. No test case created. > - Moves Tom's general-purpose getConstant method from EvaluateVisitor > to ThreadContext for use by other code. DefinedVisitor uses it for > defined? <constant>. Modified it to be a "do/while" loop so it > searches the current class first. > - Replaces old setCRef/getCRef code (where ThreadContext clients were > required to maintain the "current" CRef) with setCRef/unsetCRef and a > "current CRef stack". > > I've attached Tom's original CRef patch to make it easier to see my changes. > > I got in up to my ears on this one; it represents about 20 hours of > work. Replacing parentModule throughout with cref was a huge chore, > but it was the right way to go (parent module was just plain > incorrect). Beyond that, it was a slow, painstaking process of > re-running everything from before and hunting down specific bugs. I > believe almost everywhere that uses cref is using it correctly now, > and I've managed to eliminate all new failures (and add a few test > cases for the issues I chased). > > With this patch, everything runs at least as well as before, but the > nesting of classes and methods defined in them now works roughly the > same way as in Ruby. You'll note in certain places that we have > skipped the autoloading stuff in Ruby 1.8...obviously we'll have to > revisit that. > > This patch is only applicable to cnutter_work1, and I'm not planning > to port it to HEAD because of the large number of changes involved. > > -- > Charles Oliver Nutter @ headius.blogspot.com > JRuby Developer @ jruby.sourceforge.net > Application Architect @ www.ventera.com > > > -- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
