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.
http://debasishg.blogspot.com/2007_01_01_archive.html 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
Martin DeMello wrote:
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.
Fully agree. Also, a method like Util.rot13(string) is defined in a pretty bland namespace, so it is really almost as "global" as String#rot13. How qualified would it have to be to be safe?
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Martin DeMello wrote:
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.
I think this statement is incorrect. You CAN create a string with a #rot13 method, without adding that method to the core class.
Best regards,
Jari Williamsson
Well, you can add it individually to any given string, but I fail to
see how this affects my argument.
martin
···
On Tue, Feb 26, 2008 at 11:59 PM, Jari Williamsson <jari.williamsson@mailbox.swipnet.se> wrote:
I think this statement is incorrect. You CAN create a string with a
#rot13 method, without adding that method to the core class.
