Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Rework method invocation to properly super #5627
This PR reworks most of our method invocation pipeline to follow MRI's way to set up the frame class.
In MRI, when searching for a method in a class hierarchy, the method is returned along with the class in the hierarchy that held it. In the case of modules, this would be the included module wrapper inserted into the class hierarchy. By returning the wrapper, the "frame class" points at the proper place from which to start "supering" to the next level in the hierarchy.
JRuby's logic previously had to perform a search against the hierarchy every time a module method performed super, since we set up the frame class pointing at the module itself.
With the new logic, the CacheEntry returned from RubyModule.searchWithCache contains an additional reference to the appropriate class in the hierarchy from which to super. This eliminates the hierarchy search in all but a few places and should fix other bugs with double included modules, refinements, and prepends/includes.
This was referenced
Feb 26, 2019
enebo left a comment
I have one comment which I almost marked request changes but since it has already been inconsistent (searchMethodCommon) I will merely suggest we match those two impls to return the same tuple of things.
We talked yesterday about the potential future confusion of searchMethod versus getting the CacheEntry back. We definitely should make a blessed API for future uses of people who want to lookup and call ala callsite caching (which is probably the lambda + indy soln you mentioned). I would say we should deprecate searchMethod (although it is such a nice name). Maybe we make a new named version of searchMethod (no idea on that new name), mark it protected, use it internally, and deprecate searchMethod? I think the name is so screaming use me we should do something.