PROPOSAL: Method and Field Literals
scolebourne at joda.org
Wed Mar 11 16:37:39 PDT 2009
Jesse Wilson wrote:
> Should the type parameters include the declaring type, return type, or
> both? I prefer both.
> Method<List, Iterator> listIterator = List#iterator();
> Field<String, Comparator> aToZ = String#CASE_INSENSITIVE_ORDER;
I was only thinking of it being the return type:
Method<Iterator> listIterator = List#iterator();
Field<Comparator> aToZ = String#CASE_INSENSITIVE_ORDER;
> Should we support only raw types in type parameters (as Class literals
> do) or fully parameterized types? I believe using the raw types is
> more correct but it will require warnings suppressions in practice.
I was thinking of parameterized
Method<Iterator<String>> listIterator = List<String>#iterator();
Field<Comparator<String> aToZ = String#CASE_INSENSITIVE_ORDER;
> If a type inherits a method, which type is valid for the type
> parameter? Consider ArrayList#iterator(), which is inherited from
> AbstractList. Which of these are valid?
By only specifying the return type, you avoid this issue.
>> In summary, the real question with the proposal is whether we can
>> implement member literals independently of method references and
>> closures? The answer is definitely yes if we use the ## syntax, and
>> probably yes if we use #.
> Is there something I should mention in the proposal?
I think the proposal needs to note that a resolution of the potential
conflict with method reference/eta expansion is required. This could to
let later changes handle it, to accept method references are boxed, or
to use a different syntax. Perhaps there is another option too. (I know
Neal has some concerns on this conflict of syntax)
More information about the coin-dev