Saturday, 27 January 2007

Dot equals and the source keyword

A number of comments to yesterday's blog on a dot equals operator for overloading equals() objected to the syntax. As I tried to show, using the most logical syntax of == isn't possible in Java. Or is it?

Source keyword

Howard Lovatt has suggested using a source keyword to identify the version of the Java language that the source code is written in. This would appear before the package statement:

The addition of this keyword could allow the radical change of redefining == to === and .equals() to == in Java 7 code. Files with 'source 7' would use the new equals operators, files with source 6 (or no source keyword) would use the old equals operators.

I'll be honest - this concept seems like a 'technically it would work but its a really bad idea' thing. Redefining == in Java, so it means two different things depending on what the source version is just bound to cause trouble. Thats why yesterday's blog is seeking a new operator to represent equals().

Anyway, I include this blog just to show what is possible with syntax change - not what I actually want.

One of the downfalls of this approach is that the JLS would have to define what a java source file means with and without the "source" line... in other words, it would have to describe all supported versions of the language.

This is a question of granularity. Right now you can tell the compiler which compatibility to follow when compiling. A source keyword would hand over the decision and definition to the author of a class. For maintenance, this could be a nightmare, though. And also for people trying to understand the code.

I'd say we rather need fewer, clear rules and constructs in Java than adding piles of symbols, finally creating a new language called "Jerl". See, for example, the closure proposal. If we'd have closures earlier, we would have saved to introduce a new and partially troublesome "feature" called "Enhanced for Loop".

I very much prefer the per-source file version number (whether by keyword or filename extension). The javac tool already has to deal with multiple revisions. The JLS should be able to refer to old versions of the spec, too.

Making "==" call ".equals" (with auto null support) and make not-null the default for vars are two important changes that Java should have but can't be done in a backwards compatible fashion.

The notion of identifying the specific language used by source code is obviously correct, utterly useful, would help to mitigate new and legacy "suboptimal" language design choices (e.g. autoboxing, type erasure, annotations), and would moot all those sad "not backward compatible" excuses used to stiffle innovation.

Therefore, logically, an idea of such merit must rejected out of hand and opposed with all available resources.

Next, you'll propose removing all the deprecated stuff from the JDK. Perish the thought.