Field and Method Literals

[Joe Darcy]

Hello Chris.

Chris Beams wrote:
[snip]
> Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been.  Is there a theoretical reason why they should not or cannot be introduced?  I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around.
>
> - Chris
>
>   

Just addressing the last points on feature selection, I've written about 
this general topic a few years back:

    "Project Coin: Elephants, Knapsacks, and Language Features"
    
http://blogs.sun.com/darcy/entry/project_coin_elephants_knapsacks_language

Quoting a few paragraphs:

> Therefore for Project Coin, in addition to determining whether a 
> proposal to change the language is in and of itself appropriate, a 
> determination also has to be made as to whether the change is more 
> compelling than all but four or so other proposals. In economic terms, 
> there an an opportunity cost in the proposal selection; that is, 
> because of finite resources, choosing to have a particular proposal in 
> the platform removes the opportunity to do other proposals. There will 
> be good, compelling proposals that would improve the language /not/ 
> selected for Project Coin because there are a full set of better, more 
> compelling proposals that are more useful to include instead. Having 
> available prototypes for proposals, running the existing tests, and 
> writing new tests can only better inform the continuing proposal 
> evaluation and selection.
>
> Part of evaluating proposals is judging their utility to the Java 
> platform as a whole. In this way, I've long thought the Java platform 
> is like the elephant in the parable about the blind men and the 
> elephant <http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant>:
>
> While each Duke and each of us may know and understand our own usage 
> of Java quite well and have valid ideas about how Java could be 
> changed to improve programming in our own areas of interest 
> (properties! operator overloading! design by contract! your favorite 
> feature!), putting together all that accurate /local/ information 
> might just result in a patchwork elephant: 
> Rather than just a collection of local views, a broad perspective is 
> needed to have an accurate, unified picture of the platform so Java 
> can keep evolving and improving as a general-purpose programming 
> language. This approach favors features with broader applicability. 
> For example, a usability improvement to generics, like the diamond 
> operator which allows type parameters to be elided during constructor 
> calls, is usable more often than, say, one of the various proposals to 
> allow extensible or abstract |enum| types, a change that would only 
> helpful in a small minority of |enum| declarations. 

Cheers,

-Joe

PS Class literals weren't there right at the beginning of the platform, 
but they were added in 1.1:
http://java.sun.com/docs/books/jls/first_edition/html/1.1Update.html