PROPOSAL: Method and Field Literals (original) (raw)
Stephen Colebourne scolebourne at joda.org
Wed Mar 11 16:37:39 PDT 2009
- Previous message: PROPOSAL: Method and Field Literals
- Next message: PROPOSAL: Method and Field Literals
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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#CASEINSENSITIVEORDER;
I was only thinking of it being the return type: Method listIterator = List#iterator(); Field 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> listIterator = List#iterator(); Field<Comparator 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)
Stephen
- Previous message: PROPOSAL: Method and Field Literals
- Next message: PROPOSAL: Method and Field Literals
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]