PROPOSAL: 'final' without explicit type
Marek Kozieł
develop4lasu at gmail.com
Thu Mar 26 13:05:09 PDT 2009
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/
More information about the coin-dev
mailing list