4 ms·
So would you say that Ruby's ability to monkeypatch third-party libraries at runtime is not the type of expressiveness that "specially shines" when others have
by tobz 10y ago
So would you say that Ruby's ability to monkeypatch third-party libraries at runtime is not the type of expressiveness that "specially shines" when others have to work with your code?
Because I've had to deal with that type of shit before. Java might have a history of AbstractBuilderFactorySingletons, but you'd be hard-pressed to find an IDE that couldn't make quick work of it. Monkeypatched at runtime? Good luck!
- bazzargh 10y agoI've had to deal with both and monkeypatching isn't the worst thing, because it's static & greppable. foo.method(:bar).source_location ...and you've found the hack. In java land, third party breakage is just as common and countless times I had to decompile random jars to figure out where the bug was, and resort to strace to figure out which jars were being loaded by misbehaving classloaders. Forking a gem is preferable to monkeypatching, but sometimes this can lead to a chain of forks just to change one line in an indirect dependency, worse than the patch. No, the worst thing is method_missing. Methods that appear nowhere in the source getting invoked, and they only appear at runtime. You can do similar things with InvocationHandler in java but it gets used far, far less.
- tobz 10y agoSure, maybe not the worst thing (I don't use Ruby primarily) but just one of the many things where the "expressiveness" of the language itself is can be as much of a boon as it can be a nightmare. Misbehaving classloaders sounds like a straight up bug, or a lack of standardization around how a classloader should work. That doesn't sound so much like a failing of the language itself, but again, Java isn't my primary language so I'm not entirely privy to the landscape of Java fuckery. :)