Proposal: Enhanced String constructs for Java

Felix Frost felixf977 at gmail.com
Mon Mar 9 11:23:49 PDT 2009


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



More information about the coin-dev mailing list