PROPOSAL: Method and Field Literals

[Reinier Zwitserloot]

I have some problems with this proposal.

Let's start with my big nit:

What's this useful for, exactly? Can anyone name me one non-exotic use- 
case?

I thought of something along the lines of a library call that will  
bind 2 fields together (javafx style!) but that can't really work  
without classloader meddling, which would have to occur before you  
even make the reference in the first place. The various  
java.lang.reflect.Method/Field using libraries I've written myself  
don't operate on specific fields. They operate on any field that  
matches a certain precondition (such as having an annotation - a  
common thread). These frameworks wouldn't be helped by field or method  
literals.

I can see quite a lot of good coming from method /handles/ but if  
that's the only relevant use case, then this is some sort of closures  
light. The problem with that is future expansion: If closures do show  
up in java down the road (Closures are not going to be in java 7, but  
I don't think its valid to say they'll never be in java ever, either),  
then the one use case fizzles out, and this is going to be a niche  
feature almost never used that nevertheless has to be maintained  
forever, and the complexity tax on the parser can never be removed.  
Even if this + method handles would serve as java's only closure  
proposal, I don't really like it - I at least want a way to define a  
block on the spot. method handles are neither TCP-compliant (google  
"TCP BGGA" for info) nor do they even allow you the simple courtesy of  
in-place creation that anonymous inner class literals give you.

A related nit:

Even if there are common use-cases, Method and Field (the classes),  
well, suck. They aren't parameterized, and worse, they don't carry  
their type at runtime either in case of generified field types. In  
other words, a Field class does not carry, at compile time, the type  
of the field. However, it also doesn't carry the type of the field *at  
runtime* if the field is 'T' or 'List<T>' or anything else with  
generics in there. The few use-cases I did think of just aren't going  
to work particularly well without this information. You also can't use  
them in annotations (only primitives, String, and Class). Between  
those two, not one use-case survived. If this proposal is going to add  
any real value, it would have to include a serious overhaul of those  
two classes along with changing annotations to allow these too.  
Possibly that might push this proposal outside the intent of project  
coin.

And a very minor nit: # shows up in various closure proposals. I would  
at the very least require something on the LHS and not let just "#foo"  
default to "Field foo of my own class". For future expansion's sake.

  --Reinier Zwitserloot



On Mar 12, 2009, at 00:37, Stephen Colebourne wrote:

> 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)
>
> Stephen
>