On Tue, Sep 15, 2009 at 11:51 AM, Reinier Zwitserloot <reini...@gmail.com>wrote:
> > Oh, I'm sure it's difficult. None of that changes the fact that we're > all perfectly capable of judging new language features with: > > - a readable description that is NOT up to JLS standard. > Sections from the Project Coin proposal form ( http://openjdk.java.net/projects/coin/#proposal_form): *OVERVIEW* Provide a two sentence or shorter description of these five aspects of the feature: FEATURE SUMMARY: Should be suitable as a summary in a language tutorial. MAJOR ADVANTAGE: What makes the proposal a favorable change? MAJOR BENEFIT: Why is the platform better if the proposal is adopted? MAJOR DISADVANTAGE: There is always a cost. ALTERNATIVES: Can the benefits and advantages be had some way without a language change? > - a thorough pros and cons list > - plenty of 'real life' examples, preferably not constructed just to > highlight the feature, but created by taking existing code and > refactoring it to the hypothetical new feature > *EXAMPLES* Show us the code! SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature. ADVANCED EXAMPLE: Show advanced usage(s) of the feature. > - (optional, at least at first) some analysis on how to feasibly > extend the grammar to accommodate the feature without changing javac's > parser architecture > > compared to: > > - a JLS patch > - a prototype > > I'd argue the first list is actually quite a bit more useful. Yes, I agree, which is why the Project Coin proposal form asked for a superset of that list :-) And far > less effort to create. A serious Coin proposal can still take many hours to draft. Writing strings in switch took me 8+ hours including incorporating feedback from reviewers (and no one caught the mistake that the proposal implies one can switch on longs). Strings in switch is a one-word change to the specification; verifying it is only a one-word change makes many more words! > I'm also not hearing you say that sun engineers > themselves write up JLS chapter and verse BEFORE doing any of the > other, dare I say, far more interesting work (even if it is hard > work). As with the general engineering, the specification development is an iterative process. The final formal JLS text tends to build upon less former earlier draft specifications. However, the general sense of what aspects of the specification need updating should be determined early on. -Joe --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
