PROPOSAL: Method and Field Literals

Stephen Colebourne scolebourne at
Thu Mar 12 03:36:51 PDT 2009

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 {
   private String search;
   pivate LocalDate dateRangeStart;
   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 {
   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.


More information about the coin-dev mailing list