PRE-PROPOSAL: Source and Encoding keyword (original) (raw)

Howard Lovatt howard.lovatt at iee.org
Wed Mar 18 22:55:01 PDT 2009

Hi Jeremy,

Maybe a bit more of a motivation for source is needed, but note I am not saying that the following list should be done for 7, I am saying that these items are a possibility for some point in the future and it is a good idea to put source in now so that we are well positioned for the future. Source allows continual improvement, by allowing for incompatible changes with the past. It allows graceful aging. This is quite possible on the JVM, which is quite capable of supporting multiple languages that are quite different and hence slightly source code incompatible versions of Java that are class file compatible are no problem (they still interact with each other via the JVM).

Anyway here are some of the more ambitious changes that could be made once source is in place:

  1. New keywords, some examples from coin proposals: module (for modules), arm (for automated resource blocks), lockprotected (for concurrent lock blocks). Many current coin proposals would be improved if you could add new keywords.

  2. Big improvements to type inference could be made if a var keyword were added, like JavaFX. Going beyond what is proposed for a small amount of generic type inference.

  3. Big improvements to inner classes could be made if a method keyword were added, analogous to function in JavaFX. Some of the current inner class/closure proposals without a new keyword really stretch the syntax and are almost entirely alien to Java.

  4. Comparative operators for Comparable and equals could be added and add the same time the primitive comparisons could be fixed and a === operator could be introduced that compares address (== would call either equals or compareTo). There is a proposal in coin for operations for Comparable, but the proposal has problems because of backward compatibility issues.

  5. The switch statement could be made sane, i.e. block structured.

  6. The control blocks, if, while, for could be given return values, like JavaFX.

  7. Properties could be added, like JavaFX including bind.

  8. Traits could be added (my personal favourite).

  9. Fix generics (possibly the most requested change).

  10. etc., etc., etc.

I am sure you can see how this small change now opens up many possibilities in the future and also allows Java to pick up the best features of other JVM languages (I used JavaFX as an example above, but also Scala, JRuby, Groovey, Jython, Rhino, PHP, etc.). The above list is a very quickly drawn up list; I am sure you could add your own favourites, after all we are communicating on coin and therefore have an opinion about Java and want to see it get better. I am guessing that your personal favourite will be integrating modules with source so that version tracking of libraries can be checked by the compiler, I see this as only one of many possibilities for source.

-- Howard.

2009/3/19 Jeremy Manson <jeremy.manson at gmail.com>:

On Wed, Mar 18, 2009 at 3:10 AM, Howard Lovatt <howard.lovatt at iee.org> wrote:

Hi,

2009/3/16 Jeremy Manson <jeremy.manson at gmail.com>: I'm not objecting to versioning in principle, but I think there are enough unanswered questions that this proposal is probably beyond the scope of "small changes". I think one of the reasons that Java is tending to stagnate a little, not badly, just a little, is that it is getting hard to introduces changes. I think source will provide a relief valve - get out of jail free. I'm not going to respond point-by-point, but the primary reason it is hard to introduce changes in Java is not because of existing keywords, or the fact that we are tied to existing source.  It is because it should be hard to introduce changes in a widely used programming language.  Too much forward progress gives you a language that looks more like a katamari than a well-considered, cohesive whole: C++ and perl come to mind as examples of this.  How many different initializer syntaxes does C++ have?  15? I agree that there has been too much stagnation in the platform in the last few years, but this has nothing to do with it being difficult to change the language.  It is because of political issues in the Java community.  This is clearly not the right forum to discuss that, though. I think that in this specific case, you are considering adding something that only solves a small part of a much larger problem that needs to be addressed.  Instead of having a point solution, which risks being at odds with solutions to the rest of the problem, what you really want is a larger, well-thought-out solution to the whole problem.  Start a JSR and solve versioning for us!  Everyone will be very grateful! Jeremy

This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email

More information about the coin-dev mailing list