Opportunity Cost and Proposal Selection (original) (raw)
Joe Darcy Joe.Darcy at Sun.COM
Tue Mar 31 18:58:07 PDT 2009
- Previous message: Naked dot - accessing object fields through unqualified "." [C1]
- Next message: Opportunity Cost and Proposal Selection
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello.
There has been some traffic on the list about criteria for proposal selection (and non-selection) and I wanted to discuss that briefly.
First, a reminder from some earlier blog entries describing the context for Project Coin:
"Especially with the maturity of the Java platform, the onus is on the proposer to convince that a language change should go in; the onus is not to prove the change should stay out." http://blogs.sun.com/darcy/entry/criteria_for_desirable_small_language December 23, 2008
"Given the rough timeline for JDK 7 and other on-going efforts to change the language, such as modules and annotations on types, only a limited number of small changes can be considered for JDK 7." http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size December 11, 2008
With nearly 70 proposals submitted to the mailing list and the Sun bug database having well over 100 open "requests for enhancements" (rfe's) for the language, the large majority of those proposals and rfe's will not be included in JDK 7 as part of Project Coin or any other effort.
Project Coin will be limited to around 5 proposals total. That's it.
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 forthcoming proposal evaluation and selection.
-Joe
- Previous message: Naked dot - accessing object fields through unqualified "." [C1]
- Next message: Opportunity Cost and Proposal Selection
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]