PROPOSAL: 'final' without explicit type
develop4lasu at gmail.com
Thu Mar 26 14:38:56 PDT 2009
2009/3/26 Reinier Zwitserloot <reinier at zwitserloot.com>:
> 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
> 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
> finally, what's the wisdom in not allowing this for primitives? What's so
> bad about:
> final counter = 0;
> --Reinier Zwitserloot
It's no problem for me to forbid intersection here, or limit it to
situation when result type is 100% clear (at least for start):
final s = ( foo ? some : null );
final s = ( foo ? some : other ); // when one is ancestor of the second one.
I want this to be clear and make peoples think automatically:
final + no type => Object
while primitives have not much common with Objects I'm against mixing them here.
Pozdrowionka. / Regards.
Lasu aka Marek Kozieł
More information about the coin-dev