PROPOSAL: Method and Field Literals

[Jesse Wilson]

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<String>, Iterator<String>> listIterator = List<String>#iterator();
  Field<String, 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?
  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.