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