On 2009-02-04 04:13:38 -0500, bearophile <bearophileh...@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.for...@michelf.com
http://michelf.com/
