D versus Objective C Comparison

Michel Fortin michel.fortin at michelf.com
Wed Feb 4 03:10:39 PST 2009


On 2009-02-04 04:13:38 -0500, bearophile <bearophileHUGS at lycos.com> said:

> Instead of using a "kitchen-sink" class, in D you can put such 
> functionality into a module, like the string module of Phobos or 
> similar libs.
> 
> I don't know Object-C, what you have done looks like the "monkey 
> patching" done sometimes in Ruby. Is this the same thing?
> "monkey patching" as done in Ruby has several disadvantages and 
> dangers. Time ago I have read that there's a simple enough way to 
> remove most of the dangers from monkey patching: make it scoped. So the 
> changes to the classes can be seen just inside a scope (and its 
> subscopes) and not outside it.

>From Wikipedia <http://en.wikipedia.org/wiki/Monkey_patching>:

"In Ruby, the term monkey patch means any dynamic modification to a 
class and is often used as a synonym for dynamically modifying any 
class at runtime."

Categories are indeed monkey patching according to this definition. 
Indeed, the way categories work in Objective-C, there is some risk that 
NSString could gain a function of the same name in a future version of 
the Foundation framework, and in that case the category-defined method 
will override the "official" one, so unless you give it a name like 
MF_myMethod (sort of namespacing it with your own prefix), there is a 
risk of clash.

That said, with the extension syntax I proposed for class extensions in 
D, you wouldn't have that problem (if implemented correctly) because 
the compiler would always know from where the function is comming and 
could therfore generate code so that the right function is called even 
if a function of the same name is added to the underlying library. Hum, 
perhaps this needs more explaination.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/




More information about the Digitalmars-d mailing list