Coin Considerations

[Reinier Zwitserloot]

Static Methods in Interfaces has already been submitted. (by me and  
Roel Spilker, near the start of Project Coin).

javac should most definitely not whine about tabs, because the One  
True Indentation Style uses tabs. If anything, it should whine if you  
don't use the OTIS, but most of the java sources are in the crazy  
'indents are 4 spaces, but replace any 8 spaces with a tab' mode.  
That's one of those warnings everyone's going to turn off.

A warning for indentation that makes no sense might be more useful,  
but there are still many exceptions to this, such as giving a long  
string in the source file (code smell, but it happens) no indentation  
whatsoever to make more of it readable / require less line breaks to  
keep it all within 80 characters.

The summary: indentation style is something that keeps evolving, and  
has no concensus. That's exactly the kind of thing that should NOT be  
hardcoded into the language. If such style checking is important,  
javac needs a pluggable interface for style checking, which all the  
IDEs can than standardize upon. That's not a bad idea at all. It could  
ship with a few standard checkers out of the box, which you can then  
add to and remove from to your heart's content.

NB: OTIS is to use tabs for indentation, and spaces for spacing. The  
central rule for OTIS is: Any tab symbol may appear ONLY after either  
A) a newline, or B) a tab symbol. One of the side-effects is that you  
can mess with your editor's tab stop setting as much as you want, it  
won't break the indentation. It'll merely change it to something that  
is convenient for your eyeballs/monitor combination, one of the  
advantages of the OTIS. If you want to line things out in a source  
file (e.g. put a multi-line string's second opener right below the  
first), then tab to the usual indent, and use spaces from there for  
lining it up. This makes semantic sense; the tabs are indent, the  
spaces are spacing. Just like the names suggest.

  --Reinier Zwitserloot



On Mar 15, 2009, at 00:20, Florian Weimer wrote:

> * Reinier Zwitserloot:
>
>> Here's my list (* means: Definitely 'believe' in it, just need the
>> time, and '-' means: Not entirely sure it can be made simple enough
>> for coin / is a good idea in the first place):
>
> I would like to see:
>
>  o transient modifier on local variables
>
>    Basically,
>
>       {
>         transient SomeClass foo = getFoo();
>         doSomething(foo);
>       }
>
>   is translated to:
>
>       {
>         transient SomeClass foo = getFoo();
>         try {
>           doSomething(foo);
>         } finally {
>           if (foo != null) {
>             foo.cleanup();
>           }
>         }
>       }
>
>    were SomeClass#cleanup() is the single method in class SomeClass
>    which carries a @Cleanup annotation.
>
>    The "!= null" part is there to make it possible to signal to the
>    cleanup handler that the object has changed ownership.  Assignment
>    to the variable does not trigger cleanup, cleanup only happens at
>    scope exit.
>
>    Annotation-controlled overlading is used instead of an interface
>    because the existing cleanup routines have a myriad of different
>    names and declare different checked exceptions, too.  If there are
>    multiple @Cleanup methods for a type, a warning should be issued
>    if this happens through inheritance (old code which needs to be
>    ported), or an error if there are multiple such methods declared
>    in the same type (erroneous new code).  In both cases, if such a
>    type is used in a transient local variable declaration, the
>    declaration is rejected.
>
>    Syntactically, this extensions blends well with type inference for
>    local variables.  However, similar to other forms of compile-time
>    overloading, removing type declarations will change invoked
>    methods in a few corner cases.
>
>    The choice of the transient keyword means that the same syntax
>    cannot be used for generating cleanup methods for classes.  It is
>    not clear to me how to generate code for such classes in the
>    presence of inheritance and exceptions, so I don't think this is a
>    significant problem. (This problem does not arise in the local
>    variables case because there is a clear nesting of scopes.)
>
>    My hope is that such an extension eventually leads to code which
>    has got fewer resource leaks, but is as succinct and as easy to
>    read as code which (improperly) relies on garbage collection.
>
>  o new-style for loops with non-Iterator iterators.
>
>    Basically, allow interfaces besides Iterable and Iterator, guided
>    by annotations (a more complicated variant of the approach for
>    "transient").  The use case are iterators which may throw
>    IOException (and other checked exceptions, of course).
>
>    This is likely a waste if Java gets something which allows you to
>    define new control flow constructs (and even syntactically
>    lightweight anonymous classes might be good enough).
>
>  o "class Foo extends ?" syntax for code injection through JSR 269
>
>    Right now, you have to use a class name instead of "?" which you
>    shouldn't use anywhere else due to concerns for circularity.  Not
>    being able to name that class increases robustness.  The compiler
>    would automatically generate a suitable type name in the same
>    package as the class that contains the "?".  This would also
>    enable code injection for nested types.
>
>  o injection of automatically generated superinterface using JSR 269
>
>    IIRC, there is a bug which prevents this from working.  I don't
>    know if this is deliberate.  The syntax extension for classes
>    might help here, too.
>
>  o static methods in interface types
>
>    This is for injecting code using a superinterface generated in a
>    JSR 269 scenario.  Static member classes already work today (if
>    you fix the bug mentioned in the previous item.)
>
>  o compiler warnings for crass mismatches between syntax and
>    indentation (if this is too hard to implement efficiently, a
>    backport of the -Xlint:braces warning from Netbeans)
>
>    A mode which rejects tab characters in the source code might be
>    useful, too.
>
> My larger wish list includes:
>
>  - non-nullable reference types
>  - tuples and structural record types
>  - algebraic data types
>  - type classes and type families
>    (or reified generics with partial specialization)
>  - non-hashable/comparable/synchronizable reference types
>    (perhaps via type classes)
>
> Okay, this list is not to be taken completely seriously.  But I think
> some of the stuff is indeed useful (the last point would allow a clean
> implementation of fixnums, for instance).
>
>>  - factory interfaces (an interface to describe constructors and
>> static methods). I've got a simple way to do it, but I don't think  
>> its
>> simple enough for coin.
>
> Method handles will cover many use cases, I think.
>