PROPOSAL: 'final' without explicit type

[Marek Kozieł]

2009/3/31 Reinier Zwitserloot <reinier at zwitserloot.com>:
> Yes, the type of the RHS of:
>
> final list = foo ? new LinkedList() : new ArrayList();
>
>  is indeed AbstractList<RAW> & Cloneable & Serializable.
>
> The question is: Is that what you make the type of 'list'? That would
> be a novel idea: Now we have type variables that can have intersection
> types, not just expressions. There's nothing inherent in java stopping
> you from doing this for local method variables as you said, but one
> should consider the future impact of this: There is absolutely no way
> to specify intersection types in either java or in any sort of
> reflection tool. Any attempt to add introspection of any sort to types
> of method locals is thus going to be a major issue in the future if we
> allow intersection types for them. I don't think this proposal
> suggests you're allowed to infer the type on fields, regardless of the
> issue of intersection types, but what if that seems useful later on?
> Then either we overhaul java.lang.reflect, -or-, we all of a sudden
> exclude it for fields but allow it (to be backwards compatible) for
> method locals. Ugh. Feels hacky.
>
> I would -strongly- suggest at least for project coin to just not allow
> intersection types at all, period.

I have same opinion, just added most logic way to handle it, while
people want it a lot.
Of course if we say about effect of intersection, not intersection at
expression;

> A future version of java can add
> this support later if it is deemed important. This is analogous to how
> java gained intersection types in the fist place, which wasn't in the
> earlier versions of java. Until intersection types, the following
> expression wasn't even legal:
>
> foo ? new LinkedList() : new Arraylist();
>
> because the type of the expression (and thence also must be the type
> of the third arugment to the ?: operator) is decided by the type of
> the second argument (in the above example, 'LinkedList', and ArrayList
> is not a LinkedList.
>
> this was added without any backwards compatibility issues. The same
> can be done for making method local variables support intersection
> types.
>

Totally agree.

> Note that according to Neal, the complete lub of
> Collections.emptyList() and new ArrayList() is JUST 'List<RAW>' and
> nothing else, because one of the intersections is a strict subtype of
> the other. This is nice, because that would mean that even if we don't
> allow intersection types for method-locals, the following:
>
> String foo = someCall();
> final list = foo == null ? Collections.emptyList() : Arrays.asList(foo);
>
> would be legal, and would make 'list' be type "List<String>".
>

I'm not sure about that.
I mostly use my own collection so I do not have much problems with
such situations.
Warning may be solution here.

>
> A casual glance at large swathes of code finds almost no instances
> where I want to shorten my final method-local declaration by excluding
> the LHS type, but where I would not be able to because the expression
> on the RHS has an intersection type. The slight penalty of being long-
> winded in those situations is not as big as the potential for future
> pain, IMO.
>
> Marek: I got it right. expressions in java routinely have intersection
> types. Just try to ascertain what the type is of:
>

Then we agree here as well.

>
> 'foo ? new LinkedList() : new ArrayList()'. It's Serializable &
> Cloneable & AbstractList<RAW>. Expressions have had such types since
> java 1.4 (1.5? - whichever one relaxed the ternary operator typing).
> The entire point of discussion here is: Do we extend this intersection
> concept to the type of *variables*? Currently only expressions and the
> bounds on generics parameters can be intersections.
>
> Remi: Which problems do you see? Muchos gracias for a link to the
> proposal.
>
>  --Reinier Zwitserloot
>



-- 
Pozdrowionka. / Regards.
Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/