PROPOSAL: Method and Field Literals (original) (raw)

Jesse Wilson jesse at swank.ca
Wed Mar 11 11:29:10 PDT 2009

Thanks Stephen. I've added a link to the FCM proposal. Naturally this proposal is heavily influenced by your work. I've added TODOs for your suggestions to the spec on Google Docs.

On Wed, Mar 11, 2009 at 6:11 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

- I believe that adding generics to Field and Method (the return type) is a key part of this change. Agreed, but it does complicate things....

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;

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. Method<List, Iterator> listIterator = List#iterator(); Field<String, 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? A: Method<ArrayList, Iterator> hashCode = ArrayList#iterator() B: Method<AbstractList, Iterator> hashCode = ArrayList#iterator() C: Method<List, Iterator> hashCode = ArrayList#iterator() Each solutions has it's own pros and cons. My preference is to allow A only. A is good because it means the code won't break if ever ArrayList overrides it's iterator() method. B is good because it means the Method.getDeclaringClass() return type is consistent with the first generic parameter. But it breaks if ArrayList overrides iterator(). C is bad because the method cannot be reflectively invoked with an arbitrary List.

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?

BTW, I do think that member literals are exactly the kind of change Java needs, as they remove a very painful use of strings and exceptions today. See http://incubator.apache.org/click/docs/why-click.html (section 3) for an example of strings for method names in use today. In all the FCM feedback, method literals and references have been clearly popular. Thanks. I'm hopeful that Project Coin will live up to its promise.

More information about the coin-dev mailing list