Views
- State: published
Why foreach is Disruptive
|
|
A freeroller blogs (sorry couldn't figure out your name):
we can now write
for (String s : c) {
...
}
Although it's just syntax sugar I would have preferred this notion foreach (String s in c) {
...
}
The second one looks much clearer, however, the first is less disruptive. The keywords "foreach" and "in" may be used in older code, thus break its compilation. The introduction of the "assert" keyword in 1.4 had this same problem.
The question then is, should we sacrifice readability for convenience and compatability? So Rule 1 is non-disruptive language extensions is, don't create new keywords!
The rule looks right, however it seems extremely restrictive to me. There's got to be another way, ideas anyone?
I've got one "keyword namespaces"! The idea comes from JEX, that has a uninversal way of embedding expression languages. So here goes, it'll look like this:
c:foreach (String s in c) {
...
}
Looks a bit ugly, however if you had some way of declaring default name space for a keyword:
ns:namespace("jdk1.5" );
then it'll look like the original. (note: why is "in" not qualified, it doesn't have to be because its inside foreach)
The extension of this is that expression languages can be embedded as first class entities in the language. A problem with expression languages like jexl or jxpath is that type checking is absent. So you can't see if you have a problem at compile time.
Withe "keyword namespaces", you can create new keywords without breaking compatibilty.
Last modified 2003-07-30 04:16 PM

