Post listing the challenges of creating a refactoring browser for Ruby. The answers to these challenges smell like Smalltalk to me, although I have very little Smalltalk experience.
Avi Bryant's post about how Java and Ruby are simply playing catch-up to Smalltalk.
A small refactoring browser for Ruby already exists for Emacs.
Here is available refactorings at the moment.
* Rename local/instance/class variable
* Rename method
* Rename constant(including class name and module name)
* Pull up/Push down method
* Extract method
* Extract superclass
Ruby scripts refactored by RRB must be fulfill these conditions.
1. All ruby scripts you want to refactor must be loaded on emacs.
2. Also, all *.rb loaded on emacs are regarded as targets of refactoring.
3. Scripts must be separated into the definition part and execution part.
1 is for the possibility that any scripts can be changed after applied refactoring.
2 is for the difficulty of judging which script should be treated as a target of refactoring.
3 is for the case of using Ruby's reflection to analyze scripts.
It is necessary that nothing will be done when they are just required.
Concretely, please use the technique “surround the execution part if $0 == __FILE__ ... end”
Here's an interesting Avi Bryant article from the recent Joel vs. Ruby that seems to be related to this topic:
A proper implementation of a duck typed language will get method calls down to a single jump plus a single compare, 95% of the time. There’s no vtable indirection needed, which means that it’s generally faster than C++, because branch prediction works and the pipeline doesn’t stall.
How does that work? Well, even with duck typing, almost all method call sites have a single implementation that’s used way more than any other (say, a default superclass implementation that’s occasionally overridden by subclasses). So a proper compilation of that method call will involve first a JMP to the most likely implementation, followed by a CMP to see if you’re actually in the right place. Only if you’re not do you have to go through the full hash table lookup Joel is describing, and that happens so rarely, the extra time it takes gets practically lost in the noise.
How do you know what the most commonly used implementation is? You don’t need static analysis, just runtime profiling: the first few hundred times you do a method dispatch, store statistics about the results at the call site. Eventually, you can replace that call with the optimized version described above.
tags: ComputersAndTechnology
