Proposal: Enhanced String constructs for Java

Enhanced String constructs for Java AUTHOR(S): Felix Frost (felixf977 at gmail.com) *OVERVIEW* Java is aging and failing to keep up with the needs of the modern internet age. This proposal conservatively extends Java with some features found in more modern internet ready language in order to ensure its continued relevance. FEATURE SUMMARY: This proposal extends Java with two new multi-line capable String constructs. One is primarily concerned with embedded text, while the other simplifies the construction of helpful error messages. The HAI ... KTHXBAI string expressions allow the use of embedded emoticons. This multi-line string construct begins after the HAI keyword and ends with a KTHXBAI keyword. It also allows the use of emoticons as literals in strings. :o is usable as the system bell character ('\g'). :) should be synonymous with character U-263A(White Smiley) (☺) (available from windows arial font) :( should be synonymous with unicode character 0x2639 (Sad Smiley) (☹) :0 should be synonymous with character U-203C(Double Exclamation) (‼) (available from windows arial font) :: parses as a regular : characters The OMG ... DO NOT WANT string expressions allow for easier throwing of runtime exception. This multi-line string construct begins after OMG and end with DO NOT WANT. It converts directly into "throw new RuntimeException("<string>");" This string also supports the embedded emoticons listed above. MAJOR ADVANTAGE: Emoticons are common occurrence in most internet conversations. They can be more expressive than words, and are fun to type. MAJOR BENEFIT: This would help improve Java's popularity among the new internet generation. It will continue to stay relevant, as well as support feline developers. MAJOR DISADVANTAGE: Associated costs in documentation, tutorials and overall language size. The principle perceived disadvantage, however, is that it encourages, rather than discourages, the leveraging of hilarity in code. There are some software shops in which humor is not appreciated. For these shops, the author(s) recommend using the traditional java syntax ALTERNATIVES: It is possible to continue using the \g escape for bells, however this will likely decrease LOLs and general happiness of java developers. *EXAMPLES* SIMPLE EXAMPLE: Exclaiming in Strings - try { if(unexpectedError) { System.out.println(HAI O NOES :o KTHXBYE); OMG Sistemz iz no gud! DO NOT WANT } } catch(RuntimeException e) { //We will make it here } *DETAILS* SPECIFICATION: Lexical: HAI := 'HAI' KTHXBYE := 'KTHXBYE' OMG := 'OMG' DO_NOT_WANT := 'DO NOT WANT' Syntax: lolteral := HAI any_char* KTHXBYE can_haz_string := string_literal | lolteral o_noes := OMG any_char* DO_NOT_WANT //Replace all occurences of string_literal with can_haz_string TESTING: This feature can be tested by presenting the new java compiler to the developers pet cats, and determining the new level of programming ability. LIBRARY SUPPORT: No library support is required. REFLECTIVE APIS: No reflective APIs require any changes. OTHER CHANGES: No other platform changes are required. MIGRATION: No migration of existing code is recommended. These new language features are mainly to be used for feline developers. *COMPATIBILITY* BREAKING CHANGES: No breaking changes are caused by this proposal. EXISTING PROGRAMS: Because the changes are purely the introduction of new expression forms, there is no impact on the meaning of existing code. *REFERENCES* URL FOR PROTOTYPE: No Java prototype exists at this time. However, LOLCode[1] is the closest implementation. OTHER REFERENCES [1] LOLCode 1.2 Specification - http://lolcode.com/specs/1.2