PRE-PROPOSAL: Source and Encoding keyword

[Jeremy Manson]

I wasn't denying that this could, conceivably, allow you to make
sweeping changes to the language more easily.  I never claimed there
wasn't a motivation for this change.  My point was and remains that
versioning of sweeping changes to the language is only (a relatively
small) part of a much larger problem of versioning, and it would make
more sense to tackle the large problem than to add this keyword (which
may or may not fit with a larger solution, when all of the parts of
the larger solution are in place).

Jeremy

On Wed, Mar 18, 2009 at 10:55 PM, Howard Lovatt <howard.lovatt at iee.org> wrote:
> 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
>> ______________________________________________________________________
>>
>