rails/rails — pull request #17633 by notEthan (2014-11-16 06:39:07+00:00)
Title: Replace class_eval

this is the start of an undertaking I've wanted to do for some time. rails uses class_eval and related methods that put its ruby into interpreted strings rather than directly in the ruby source, all over the place. it is a pain for a number of reasons (elaborated below), and I want to replace it.

I've done this in a few places to start with here, but I'd like to discuss before I proceed further and determine whether this is a thing that is likely to be accepted.

downsides of ruby being in strings to class_eval:

- for me the most major one is that every debugger I have used (ruby-debug / ruby-debug19 / debugger / byebug / rubinius-debugger) either lose track of where the code being executed lives (despite the `__FILE__, __LINE__ + 1` stuff), or just don't even know how to look for it. I use the debugger extensively to trace execution through rails when documentation is insufficient, and almost every time I end up having no idea where I am due to these string code blocks.
- error backtraces similarly can get confused and point to the wrong thing
- more readable, and more concise code - interpolating variables into ruby strings of code is confusing and ugly
- text editors' syntax highlighting can't reliably parse it - even when the text editor recognizes it as ruby inside a string, parsing can break easily and string interpolation within it can get particularly weird.
- just elegance. code straight in the source is much nicer then code in big blocks of text. but that's my opinion more than any solid, real reason.

downsides of define_method / define_singleton_method:

- the only reason I know not to use define_method has been the lack of support for &block in ruby 1.8, but now that 1.8 is unsupported, I know of no reason not to.

all tests still pass with these changes.

what do you think, rails friends, is this a thing that can go in?