open classes and language extensibility

[Martin DeMello]

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.

 

[Joel VanderWerf]

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?

 

[Jari Williamsson]

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

 

[Martin DeMello]

I think this statement is incorrect. You CAN create a string with a
#rot13 method, without adding that method to the core class.

Well, you can add it individually to any given string, but I fail to
see how this affects my argument.

martin

 

[J. Cooper]

because String was a core class, you'd be forced to say rot13(string),

martin

Welcome to PHP