PRE-PROPOSAL: Source and Encoding keyword

[Howard Lovatt]

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
> ______________________________________________________________________
>