Proposal: Elided type specification for initialized final value declarations. (original) (raw)

Mike Elliott mre at m79.net
Mon Mar 30 20:32:02 PDT 2009

See attached PDF for a prettier version, but here's the text:

Title:

Elided type specification for initialized final value declarations.

Author:

Mike Elliott – The Boeing Company

Overview:

The use of the final keyword in declaring an initialized value (since it's final it's not really a “variable”) is superfluous as all necessary type information is available from the right hand side of the declaration. Eliminating the type declaration will increase expressive power as well as reduce visual clutter. This feature exists to some degree in other languages – the with construct in Modula 3 for example and the untyped constant declarations and (somewhat exotic) use of renames clauses in Ada – where it has been shown to be useful in the building of complex expressions

Examples:

private final HashMap<String, SomeClass.InnerClass> map =
    new HashMap<String, SomeClass.InnerClass>();

would become

private final map = new HashMap<String, SomeClass.InnerClass>();

Since the type is completely determined by the expression on the right side of the equals sign, the type declaration on the left side of the equals sign is unnecessary and only adds visual clutter, making it more difficult to pick out the important thing, the name of the value being expressed. And since the value can never be changed the runtime determination of type, subtype, etc., is not an issue.

A visually long value building process such as

    final BufferedInputStream in =
         new BufferedInputStream(
            new FileInputStream( filename ));

is sometimes broken up into multiple declarations in order to keep the line lengths manageable, especially if there are coding conventions prohibiting physical lines which exceed 80 columns in order to encourage greater readability.

   final FileInputStream fis = new FileInputStream( filename );
   final BufferedInputStream inStream = new BufferedInputStream( fis );

While this is semantically equivalent to the previous code, it avoids unsightly line wraps. However, this would be cleaner still if the type declaration could be elided:

   final fileInput = new FileInputStream( filename );
   final bufferedIn = new BufferedInputStream( fileInput );

Note that locality of type expression is maintained. The programmer could still determine the type of the constant at the point of declaration.

Details:

This proposal makes optional the use of the type declaration when declaring final values with an initiailzer expression. The grammar would simply make this declaration optional which would break no existing code and still leave the deliberate declaration of type in this situation available if, for example, the programmer wished to use it as a sort of inline documentation. It can free up a substantial amount of screen real estate in the case of long type declarations which could be better used with a more expressive name for the constant than would otherwise fit on the line. Additionally it would encourage a greater use of the final keyword which can only help the compiler in code optimization efforts and provide greater clarity for the maintainer.

The type system itself would not be impacted. The only change in compilation would be the necessity to look ahead to the value declaration in order to determine the constant's type from the value declartion rather than have it literally expressed immediately before that value declaration. No new byte codes would be necessary.

Since this feature introduces no new functionality, no testing changes would be introduced other than to confirm that eliding the type declaration produces no changes in generated byte code.

No library support is needed, nor would there be any changes to the reflection APIs. There is no effect on JNI or serialization.

There would be an impact on JavaDoc as the type of the constant would not be immediately obvious to a post-process tool if this feature is allowed (as it probably should be) for named value declarations outside of method declarations; that is, for other than “auto class” declarations.

Compatability:

No previously existing valid programs would become invalid. No overloadings can occur other than those which already occur, such as when a class variable in a superclass is “overloaded” by creating the same class variable in a subclass (which should never have been allowed anyway, but that's another story).

References:

No known bugs related to this proposal.

--

Mike Elliott mre at m79.net

More information about the coin-dev mailing list