4 ms·

The problem with limiting monkey-patching is that it's used extensively and with great variety in Rails (and other popular Ruby projects). Monkey patching, don

The problem with limiting monkey-patching is that it's used extensively and with great variety in Rails (and other popular Ruby projects). Monkey patching, done correctly, will "settle" over time. That is, once your rails app has called all the dynamic finder methods it's ever going to use, and `require`d all of the `active_support` extensions it'll need, it's done monkey patching. Of course, there are programming mistakes that can open a huge bag of worms, such as using `OpenStruct`s. Generally, anything that will smash the global method cache[1] is also going to require the kind of `iseq` deoptimization that this pull is about (in fact, smashing the global method cache is a simple case of deoptimization). This is why deoptimization is so useful - it's almost never going to happen after your app has settled, but it's necessary to maintain correctness while `active_support` is being loaded and adding all of those yummy methods to core classes. `call_cc` can go to hell though - I've never seen a program that uses it ;-) [1] https://github.com/charliesome/charlie.bz/blob/master/posts/things-that-clear-rubys-method-cache.md https://github.com/charliesome/charlie.bz/blob/master/posts/...

qwertyuiop924 10y ago
Yeah, but there's got to be a less needlessly overcomplicated way of doing this. It's ridiculous. As for call_cc (or to use its "real" name call/cc, or call-with-current-continuation), my usual response to those that propose dropping call/cc (usually proposing shift/reset or similar as a replacement) is "over my dead body," but that's Scheme: supporting weird experiments is part of Scheme's job, and there's at least one high-quality implementation of Scheme that uses Cheney-on-the-MTA compilation, which makes call/cc fast enough for Real Work. In ruby, the situation is different: call/cc is slow, expensive, and Ruby is a language for getting stuff done, not academic experiments about control structure.

qwertyuiop924 10y ago

Yeah, but there's got to be a less needlessly overcomplicated way of doing this. It's ridiculous. As for call_cc (or to use its "real" name call/cc, or call-with-current-continuation), my usual response to those that propose dropping call/cc (usually proposing shift/reset or similar as a replacement) is "over my dead body," but that's Scheme: supporting weird experiments is part of Scheme's job, and there's at least one high-quality implementation of Scheme that uses Cheney-on-the-MTA compilation, which makes call/cc fast enough for Real Work. In ruby, the situation is different: call/cc is slow, expensive, and Ruby is a language for getting stuff done, not academic experiments about control structure.