PROPOSAL: Method and Field Literals
reinier at zwitserloot.com
Wed Mar 11 21:48:39 PDT 2009
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-
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
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
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.
On Mar 12, 2009, at 00:37, Stephen Colebourne wrote:
> Jesse Wilson wrote:
>> Should the type parameters include the declaring type, return type,
>> 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
>> 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
> let later changes handle it, to accept method references are boxed, or
> to use a different syntax. Perhaps there is another option too. (I
> Neal has some concerns on this conflict of syntax)
More information about the coin-dev