PROPOSAL: 'final' without explicit type

[Reinier Zwitserloot]

As Neal Gafter explained, lub (intersection type generator) will  
already find a common supertype if 1 of the intersection types is a  
supertype of all others. The notion of making the type 'the  
interface', if the intersection type contains exactly 1 interface, is  
a very bad idea. There is no precedent for this, and there are plenty  
of situations where this will go wrong. For example:

final list = foo ? new LinkedList() : new ArrayList();

the type of 'list' is what, exactly? Serializable? Cloneable? List?  
They're all valid, so that wouldn't work. If the feature says it will  
attempt to find a proper interface, people will wonder why that does  
not work.

or, how about:

final number = foo ? 5 : 10L;

This will result in 'number's type being Serializable, which is  
completely wrong, because that's the only common interface. People  
would expect that to become 'Number', but it won't be, because Numer  
is a class and not an interface.


finally, what's the wisdom in not allowing this for primitives? What's  
so bad about:

final counter = 0;


  --Reinier Zwitserloot



On Mar 26, 2009, at 21:05, Marek Kozieł wrote:

> AUTOHOR: Laau aka Marek Kozieł
>
> 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 increasea 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 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.
> 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
> of 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.
> - VariableInitializer type is neither primitive nor Object.
> - If VariableInitializer -Expression type is intersection type (we
> always ommit 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.
>  For first implementation this solution can omit supporting  
> intersections.
>
> 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
>
> http://bugs.sun.com/view_bug.do?bug_id=4459053
>
> http://bugs.sun.com/view_bug.do?bug_id=4983159
>
> http://lasu2string.blogspot.com/2009/03/final-without-explicit-type-proposal.html
>
>
>
> PS. Personally I think that consider operator is better, but I'll take
> time to improve this proposal while it's more Java-like.
>
> -- 
> Pozdrowionka. / Regards.
> Lasu aka Marek Kozieł
>
> http://lasu2string.blogspot.com/
>