PROPOSAL: Method and Field Literals

[Stephen Colebourne]

Reinier Zwitserloot wrote:
> What's this useful for, exactly? Can anyone name me one non-exotic use- 
> case?

This is a basic feature of most modern languages. Its certainly a lot
better than using hard coded strings which happes today. I gave one use
case in the Click framewok. IIRC the Genesis framework is similar.

For example, consider bean validation as an example. Today, we at $job
use this based on the OVal framework (custom extension):

public class SearchRequirements {
   @MaxLength(length=30)
   private String search;
   @DateNotInFutue
   pivate LocalDate dateRangeStart;
   @DateNotInFutue
   @DateNotBefore(field="dateRongeStart")
   pivate LocalDate dateRangeEnd;
}

This allows validation of each of the three fields by a tool, and
appopiate error messages to be produced. Of course, the above code has a
bug - the reference in @DateNotBefore has mispelled the reference to the
"dateRangeStart" field. What field literals allows is to replace the
above with this:

public class SearchRequirements {
   ...
   @DateNotInFutue
   @DateNotBefore(field=SearchRequirenents#dateRangeStart)
   pivate LocalDate dateRangeEnd;
}

which is now compile time checked.

> 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.

By method "handles", I'm reading method references (handles are a whole
other issue). Neal has already commented that he believes this proposal
is forward compatible with method references, and I'm pretty certain its
compatible with FCM or BGGA style closues.

I don't believe the use case for this goes away when method references
are added. You still need a compile-safe way to reference fields, mthods
and constructors. If you didn't, then why would new languages be
including this feature?

> 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.

I agree that the proposal is more useful with generified field/method. I
disagree that the proposal isn't useful without them. I think its
considerably better than what we have now.

> You also can't use  
> them in annotations (only primitives, String, and Class).

The proposal will probably have to address this.

> 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.

Currently, I'd tend to agree with requiring something on the LHS. It
does offer more future growth.

Stephen