Proposal: Improved declaration using final keyword of internal method variables and for-loop statement

[Joe Darcy]

Hello.

I don't find this proposal very compelling.  Slight performance 
differences in the client, or server, compiler can change in update 
releases.

Regards,

-Joe

On 03/31/09 02:04 AM, Andrej Navodnik wrote:
> Hi Project Coin members,
>
> here is my little proposal for improved declaration using final keyword 
> of internal method variables and for-loop statement.
>
> Is it too late? Maybe not. At the time I'm sending this e-mail, in Honolulu, Hawaii, it is still Monday, 30 March 2009.
>
> Kind regards,
> Andrei
>
> -----------------------------------------------------------------------
>
> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>
> TITLE:
>     Improved declaration using final keyword of 
>     internal method variables and for-loop statement 
>
> AUTHOR(S):
>     Andrei Navodnik (andrejnavodnik at yahoo.com)
>
>
> OVERVIEW
> ========
>
> FEATURE SUMMARY: 
> Allow declaration of mixed final and non-final internal method 
> variables in one statement and enable final keyword in for-loop 
> declaration for variables other than index variable.
>
> MAJOR ADVANTAGE: 
> Suppose that the developer wants to have as much variables defined 
> as final then if this feature were accepted in the language one major 
> advantage would be to allow shorter syntax of internal method variables.
> Mixing of final and non-final variables in one declaration statement
> would be allowed which is prohibited with the current state of the 
> compiler. The compiler either allows all variables to be final or 
> all variables to be non-final.  
>
> As far as for-loop declaration is concerned, this feature would allow 
> syntax that is more compact (no pollution of scope outside of the 
> for-loop) and "safer" (the size of the list would be assigned to final 
> variable and this value can not be changed inside of the loop).
>
> MAJOR BENEFIT: 
> Suppose that the majority of code is written as
>  
>     for (int i = 0; i < values.size(); i++ ) {
>         // ...
>     }
>
> then this feature would allow easier refactoring to the optimized 
> style of for-loops
>   
>     for (int i = 0, final n = values.size(); i < n; i++) {
>         // ...
>     }
>
> because variable n can not be already defined in the scope either 
> outside or inside of the for-loop. Any such violation would make 
> program uncompilable. According to my benchmarks the later style of
> for-loops is also slightly faster in client VM.
>
> MAJOR DISADVANTAGE: 
> If the feature were accepted then the major disadvantage in my opinion 
> would be slightly more complex grammar which would have to take care 
> of the compatibility with the existing programs.
>
> ALTERNATIVES:
> One of the alternatives to the proposed syntax (see simple example
> bellow) would be to declare internal method variables in separate
> statements, for example one statement for all non-final variables and 
> one statement for all final variables. Someone might even argue that
> syntax where each variable is defined on separate statements is better
> comparing to the syntax where all variables are defined in one
> statement.
>
>     int a, c = 1;
>     final b, d = 4;
>
> But, if developer's strategy is to define all read-only variables as
> final then the alternatives to the proposed syntax for the for-loop 
> are not very nice. One is to declare variable of the size of the list 
> outside of the for-loop declaration, for example
>
>     final n = values.size();
>     for (int i = 0; i < n; i++) {
>         // ...
>     }
> 	
> or to declare index variable outside of the for-loop.
>
>     int i = 0;
>     for (final int n = values.size(); i < n; i++ ) {
>         // ...
>     }
>
>
> EXAMPLES
> ========
>
> SIMPLE EXAMPLE:
> If the proposal were accepted then the code below should be valid. 
> Please, compare the proposed syntax with the alternatives presented
> above.
>
>     int a, final b, c = 1, final d = 4;
>     for (int i = 0, final n = values.size(); i < n; i++) {
>         // ...
>     }
>
> ADVANCED EXAMPLE:
> No advanced example.
>
>
> DETAILS
> =======
>
> SPECIFICATION: 
> To support mixed final and non-final internal method variables the 
> grammar should be changed as follows: 
>
>     LocalVariableDeclarationStatement:
>         AllVariablesFinalDeclarationStatement 
>         SomeVariablesFinalDeclarationStatement
>         
>     AllVariablesFinalDeclarationStatement:
>         final Type VariableDeclarators ;
>
>     SomeVariablesFinalDeclarationStatement:
>         Type SomeVariablesFinalDeclarators ;
>         
>     SomeVariablesFinalDeclarators:        
>         VariableDeclarator { , VariableMaybeFinalDeclarator }
>
>     VariableMaybeFinalDeclarator:
>          [final] Identifier SomeVariablesFinalDeclaratorsRest        
>
>     SomeVariablesFinalDeclaratorsRest:
>         SomeVariablesFinalDeclaratorsRest { , VariableMaybeFinalDeclarator }
>
> To better support final keyword in the for-loop declaration the grammar
> should be changed as follows: 
>
>     ForVarControl:
>         AllVariablesFinalForVarControl
>         SomeVariablesFinalForVarControl
>
>     AllVariablesFinalForVarControl:
>         final [Annotations] Type Identifier ForVarControlRest
>
>     SomeVariablesFinalForVarControl:
>          [Annotations] Type Identifier SomeVariablesFinalForVarControlRest
>          
>     SomeVariablesFinalForVarControlRest:
>         SomeVariablesFinalDeclaratorsRest;   [Expression]   ;   [ForUpdate]
>         : Expression
>
> TESTING: 
> No specific testing is needed to test this feature.
>
> LIBRARY SUPPORT:
> The proposed language feature needs no additional library support.
>
> REFLECTIVE APIS: 
> The feature does not affect reflective API's.
>
> OTHER CHANGES: 
> The feature does not need other changes.
>
> MIGRATION:
> Existing programs should work without any change.
>
> COMPATIBILITY:
> All existing programs are compatible.
>
> BREAKING CHANGES: 
> None.
>
> EXISTING PROGRAMS:
> There should be no impact on existing programs.
>
>
> REFERENCES
> ==========
>
> EXISTING BUGS: 
> RFE has been already filed for this feature, please check internal
> review ID 1200191.
>
> URL FOR PROTOTYPE:
> There is no prototype for this feature.
>
>
>
>
>       
>
>