I was pondering the whole “monkeypatching” debate, and I realised that
disallowing modification of core classes removes an extremely
important property of the language - the ability to have extension
code you write be “on par” with the base language. This is often
touted as one of the big advantages of lisp and forth, and it would be
a shame to lose it in ruby. For instance, lets say your code relied
heavily on rot13. If you couldn’t add a #rot13 method to String
because String was a core class, you’d be forced to say rot13(string),
or even worse, Util.rot13(string). You’d end up with expressions like
rot13(string.capitalize.squeeze), where it is very clear which methods
come from “base ruby” and which are yours.
Ruminations of a Programmer: January 2007 is a good read
on the subject:
With a Lisp implementation, we can have a natural extension of the
language through a macro
dolist (x '(1 2 3)) (print x) (if (evenp x) (return)))
and the moment we define the macro, it blends into the language syntax
like a charm. This is abstraction through syntax construction.
And, the Java counterpart will be something like :
// …
Collection<…> list = … ;
CollectionUtils.dolist(list,
new Predicate() {
public boolean evaluate() {
// …
}
});
// …
which provides an object oriented abstraction of the same
functionality. This solution provides the necessary abstraction, but
is definitely not as seamless an extension of the language as its Lisp
counterpart.
martin
