PROPOSAL: Method and Field Literals (original) (raw)
Stephen Colebourne scolebourne at joda.org
Wed Mar 11 06:11:09 PDT 2009
- Previous message: PROPOSAL: Method and Field Literals
- Next message: PROPOSAL: Method and Field Literals
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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=dhfm3hw262dxg677jn
Proposal: Method and Field Literals AUTHOR(S): Jesse Wilson
- Previous message: PROPOSAL: Method and Field Literals
- Next message: PROPOSAL: Method and Field Literals
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]