PROPOSAL: 'final' without explicit type (update)

[Gabriel Belingueres]

Hi Marek:

- VariableInitializer type is neither primitive nor Object.
 --> primitive : they should not be mixed with Object-s to easy.
 --> Object : when object type is Object, we mostly deal with
situation 'Unknown type', so this should not be hidden.

I still don't get why it is so bad to do something like this:
final a = 1; // static type is int
or
final o = new Object(); // static type is Object, no doubt

I still don't see the point on not making this feature more orthogonal
(unless some convincing argument is presented against it.)


2009/3/30 Marek Kozieł <develop4lasu at gmail.com>:
> AUTHOR: Lasu aka Marek Kozieł
>
> OVERVIEW
>
> FEATURE SUMMARY:
>
> MAJOR ADVANTAGE:
> It allows people to concentrate on logic during operating on heavy
> generics and to use values which are more intuitive for them than
> variables.
>
> MAJOR BENEFIT(s):
> - It allows to avoid duplicating unnecessarily types of declaration.
> - It increase a concentration on 'what I've got' than on 'what type is
> that' (we decrease size by one to obtain last element index, not
> because we can do this = it's int), while for variables we still keep
> concentrate on: 'what type is that' / 'what I can put there'.
> - Editing existing code to get some value from method chain is easier.
> - That method can be itself multi-thread with this, but it's a far future.
> - Using of Generics is easier.
>
>
> MAJOR DISADVANTAGE:
> Certainly, some people will overuse this solution.
> Consider operator is easier to read.
> It might be a problem if a person does not know how to give proper
> names for values.
>
> ALTERNATIVES:
> Normal variables.
>
>
> EXAMPLES
>
> SIMPLE / ADVANCED EXAMPLE:
>  public Map<String,ArrayList<String>> readMaping(){
>    final map = new HashMap<String,ArrayList<String>>();
>    for( final row : readLine() ){
>      String key = row.get(0);
>      row.remove(0);
>      map.put(key, row);
>    }
>    return map;
>  }
>
>  public Map<String,ArrayList<String>> readMaping(){
>    final map; //compile time error
>    map= new HashMap<String,ArrayList<String>>();
>    for( final row : readLine() ){
>      String key = row.get(0);
>      row.remove(0);
>      map.put(key, row);
>    }
>    return map;
>  }
>
> public class Final {
>  static final maping = new HashMap<String, ArrayList<String>>();
> }
>
> public class Final {
>  static final maping = (Map<String,ArrayList<String>>)loadMap();
> }
>
> DETAILS
>
> SPECIFICATION: FieldDeclaration
> FieldDeclaration would be extended to allow omitting Type declaration
> if field is final and it's directly followed by assignment of new
> class instance creation(created object type would be used), or by
> Anonymous Constructors (JLS 15.9.5.1 )(direct superclass S would be
> used), or Enum constants preceded by EnumType (JLS 8.9) (Enum type
> would be used), or CastExpression (JLS 15.16) (ReferenceType would be
> used).
>
> SPECIFICATION: LocalVariableDeclarationStatement
> (JLS 14.4) Local Variable Declaration Statements would be extended to
> allow omitting Type declaration if field is final and listed rules
> taking place:
> - VariableInitializer appears.
> - Variable is not initialized directly with null (this can be discussed).
> - VariableInitializer type is neither primitive nor Object.
>  --> primitive : they should not be mixed with Object-s to easy.
>  --> Object : when object type is Object, we mostly deal with
> situation 'Unknown type', so this should not be hidden.
> - If VariableInitializer - Expression type is intersection type (we
> always omit Object type in intersection), then:
>  --> If intersected types have common ancestor then this ancestor is
> used as type.
>  --> If effect of intersected types is one Interface, then this
> interface is used as type.
>  --> In other way, an error occurs.
>
>
> COMPILATION:
> Just as today, value type only need to be determined.
>
> TESTING:
> The same as final-s variables.
>
> LIBRARY SUPPORT:
> No.
>
> REFLECTIVE APIS:
> No.
>
> OTHER CHANGES:
> No.
>
> MIGRATION:
> None.
>
> COMPATIBILITY
> Only code is no forward compatible.
>
> REFERENCES
>   RFE: Add Immutable types to Java:
> http://bugs.sun.com/view_bug.do?bug_id=4459053
>
>   Typedef (alias):
> http://bugs.sun.com/view_bug.do?bug_id=4983159
>
> http://lasu2string.blogspot.com/2009/03/final-without-explicit-type-proposal.html
>
>