PROPOSAL: Method and Field Literals

[Reinier Zwitserloot]

I find both use-cases given so far not very compelling.

Stephen Colebourne's Use-Case 'annotations for OVal framework':

That can't work with this proposal because Fields aren't allowed in  
annotations. This was part of my point: You need to do quite a job on  
the rest of the JLS and a good chunk of the reflection API to make  
this useful. It's not a bad idea perse, but the value of this proposal  
divided by the effort and impact isn't a very high number (IMO).

Adrian Kuhn's 'jexample' jUnit extension:

Again with the annotations. Also, that's rather exotic. I'd just solve  
this differently. First off, between checking the stacktrace at the  
point of a failed assertion, -or- doing some class-file-fu to see that  
a given fixture calls another unit test method, any fixtures calling  
another fixture for setup purposes can be skipped without any  
annotation. Most unit tests are sequential in design so an annotation  
of the form "@Sequential" would tell the unit test framework to skip  
the test if any previous tests failed. Methods are given in order in  
the class file itself, but technically Class.getMethods() does not  
return the methods in order according to the javadoc, though in  
practice it does. A proposal to make that official works for me.


If I compare this to other project coin proposals, the use cases just  
don't have the wow factor for me.

The intent of this nit is to improve the proposal by making sure it  
lists all the changes needed to make it useful, and includes a listing  
of excellent use-cases so that, if the proposal is adopted, the  
proposal can be explained to the masses that use java in a way that  
makes them go: Ah, how useful!

It would be a shame if they went: Why is this in here? Proposal  
<insert pet proposal here> is so much simpler and has so much better  
value. Java7 sucks! Bad java7! I'm going to go blog about it now! -  
Developers are a bunch of whiny kids sometimes :P Alternatively they  
forget all about it because it wasn't compelling to them and then you  
get the unfortunate situation that there's another piece of syntax  
that most java developers don't know about. I'd prefer to keep such  
niches of the JLS (like strictfp) to a minimum. It's not good for the  
language.

  --Reinier Zwitserloot



On Mar 12, 2009, at 11:36, Stephen Colebourne wrote:

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