PROPOSAL: Method and Field Literals

[Stephen Colebourne]

I have thought for some time that this is one of the least
controversial parts of FCM
(http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc , which really should
be referenced).

My take on the comments so far:

- Constructor literals have to be included. If you don't then
developers will find it an unexplained gap. See FCM section 2.2 which
uses Type#(argTypes)

- I agree with Neal, in that the LHS should be a standard LHS.

- I would use Field/Method/Constructor, as a key goal is to enable
integration with existing frameworks.

- I don't find MethodHandle especially compelling, as it feels too low
level. It would also differ from the use of Field/Constructor. I
assume that Method will be retrofitted with a way to get a
MethodHandle.

- I believe that adding generics to Field and Method (the return type)
is a key part of this change.

- One area that needs to be added to the spec is to allow member
literals in annotations. Currently, annotations are defined to only
accept a limited subset of types that are known to be safe and
immutable. There is a use case for frameworks to link to methods and
fields from annotations (currently it is done using strings). The
problem is that Field/Method/Constructor are not immutable. However,
it has been suggested to me previously that a clone can be returned
each time from the annotation.

- Properties are out of scope. Properties are (currently) a pair of
get/set methods. As there is no language support for that, it doesn't
fit the model being used here. I personally think that Java would be
vastly better off with properties, but they would need to be very
deeply integrated, and thats not currently on the agenda


Finally, it must be noted that adopting this approach to member
literals implies the equivalent of boxing should you want to support
FCM method references or BGGA eta expansions (same concept and syntax,
but different name). There is a way avoid the boxing, by using a
double hash: String##substring(int).

Thus, it could be argued that both member literals and method
references should be designed together (and implemented together) to
ensure a consistent design. Unfortunately, this leads on to the vexed
question of BGGA function types which Coin cannot address.

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

BTW, I do think that member literals are exactly the kind of change
Java needs, as they remove a very painful use of strings and
exceptions today. See
http://incubator.apache.org/click/docs/why-click.html (section 3) for
an example of strings for method names in use today. In all the FCM
feedback, method literals and references have been clearly popular.

Stephen


2009/3/11 Jesse Wilson <jesse at swank.ca>:
> Rich text (preferred) here:
> http://docs.google.com/View?docID=dhfm3hw2_62dxg677jn
>
> Proposal: Method and Field Literals
>
> AUTHOR(S):
> Jesse Wilson