monkeypatching

I've heard a lot of oohs and aahs about how monkey patching is so cool or monkey patching is the worst thing on earth. I have the idea that it's not good if you write some code and then someone else changes its functionality to do something else. But I'm looking for a concrete example of a situation where this could really hurt you. I mean, I write code all the time and then my coworkers make changes to it. So, how is monkey patching any different from that? What's the worst that could happen ? Programming has had a slow but steady movement away from coding practices that require understanding

I've come across an issue with ActiveResource that has been resolved and was trying to monkey patch it into my application without much luck. I've added a file in config/initializers/ containing the following: class ActiveResource::Errors < ActiveModel::Errors # https://github.com/rails/rails/commit/b09b2a8401c18d1efff21b3919ac280470a6eb8b def from_hash(messages, save_cache = false) clear unless save_cache messages.each do |(key,errors)| errors.each do |error| if @base.attributes.keys.include?(key) add key, error elsif key == 'base' self[:base] << error else # reporting an error on an

I have a @memoize decorator in my models, which caches some details on the model itself, to avoid multiple database calls when called many times (especially in templates). However, since I store the objects and refer to them in tests, this breaks things. For example, if I do mygroup.subscribers , add a subscriber and try it again, it will return an incorrect number of subscribers, since it's been memoized. How can I monkey-patch that decorator to do nothing from my tests.py? I haven't found a way to do it cleanly, since models get loaded first. Thierry Lam At the beginning of memoize