As it happens, I ran across a situation requiring a "monkey patch" just this morning. A BottomFeeder user reported an issue reading this feed:

http://community.devexpress.com/blogs/alansplace/rss.aspx

I fired up an image, and tried this code, to make sure that the problem wasn't some silly thing I was doing in my own code:

HttpClient new get: 'http://community.devexpress.com/blogs/alansplace/rss.aspx'

Sure enough, there was a problem in the base network code in the system - something about parsing headers. Now, the correct answer here would be to go to the root of the problem, figure out the parsing error, and fix that. I could also just decide this - in the world of feed readers, cookies simply aren't that critical. So, I overrode the inherited method and did this (and yes, it's a hack):

parse: rfc822Stream
"Override to handle errors"

	self source: rfc822Stream asStream.
	value := [self doParse: rfc822Stream]
		on: Error
		do: [:ex | nil].

However, from a patching perspective, even a full fix by me would still be a patch on library code. Either way, I have to deliver a work-around to deployed clients. So what would the purist suggest in this case? Tell people in the field that they have to wait? Derive a secondary network library in order to avoid patching system code? My solution seems more pragmatic, especially since it's versioned in its own package, and - like other such patches in the past - will disappear as soon as a proper update comes from Cincom engineering.

Technorati Tags: code overrides, smalltalk, dynamic language, monkey patching