From brucechapman at paradise.net.nz Wed Jul 1 01:45:15 2009 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Wed, 01 Jul 2009 20:45:15 +1200 Subject: Thoughts on unified integer literal improvements In-Reply-To: <4BA7F830-DC6F-417D-B0F9-37968D25AC02@Sun.COM> References: <4A1DC533.2060202@sun.com> <4A488FE5.60309@sun.com> <1246328700.4a49777c21249@www.paradise.net.nz> <4A497AEA.5090803@sun.com> <4A49AF0E.3010202@paradise.net.nz> <4A49B80B.3080704@sun.com> <4A49D7B8.8060104@paradise.net.nz> <4BA7F830-DC6F-417D-B0F9-37968D25AC02@Sun.COM> Message-ID: <4A4B221B.90106@paradise.net.nz> Max (Weijun) Wang wrote: > "a new literal syntax for a literal whose type depends on the literal > value". > > So, 0xFFu, being two bytes long, is always a byte? Then what does this > line mean? assuming you mean 2 nibbles long... > >>>>> int i = 0xFFu // 127 (should be 255); > Or is this only Joe's 0xFFu? Your i will be -1? Correct - with autosizing and leading zero (under consideration) you could do it like this, forcing a zero high bit, making it nine bits minimum and therefore the type of the hex literal would be short, that would then widen to and int with value 255. assert 255 = 0x0FFu > > Got it. I would prefer 0xFFy. > > How about a step further like -- > > byte[] bs = 0x0102030405060708AABBCCDDEEFFy; > Thats a new array literal syntax, and not what is intended for coin. >> I have been writing code doing low level protocol byte munging stuff >> for years, > Me too, http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7360321c37e3 Ahh, ASN.1, is it a love/hate relationship for you? :) Bruce From brucechapman at paradise.net.nz Wed Jul 1 01:49:20 2009 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Wed, 01 Jul 2009 20:49:20 +1200 Subject: Thoughts on unified integer literal improvements In-Reply-To: <092FDA2C-172D-41E2-B857-C335F03EC4E7@zwitserloot.com> References: <092FDA2C-172D-41E2-B857-C335F03EC4E7@zwitserloot.com> Message-ID: <4A4B2310.4050102@paradise.net.nz> Reinier Zwitserloot wrote: > I don't think Artur's issues are particularly tough nuts to crack (in > that they have an easy and obvious right answer - see end of this > post), but I do have some rather serious reservations about this byte > array literal syntax: > Don't sweat it, a new byte array literal syntax is not being considered under project coin. > Seriously - where does it end? before it starts. Bruce From Alex.Buckley at Sun.COM Wed Jul 1 14:57:37 2009 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Wed, 01 Jul 2009 14:57:37 -0700 Subject: Thoughts on unified integer literal improvements In-Reply-To: <1246327948.4a49748c319ae@www.paradise.net.nz> References: <4A1DC533.2060202@sun.com> <4A488594.2010000@paradise.net.nz> <4A4908A3.3020307@sun.com> <1246327948.4a49748c319ae@www.paradise.net.nz> Message-ID: <4A4BDBD1.20904@sun.com> brucechapman at paradise.net.nz wrote: > In the original autosizing which was just for hexadecimal, the size was > specified based on the number of digits. When you extend it to decimal and octal > as well, basing the size on number of digits gets real ugly, real fast. So "as > small as possible" seems more natural. A leading zero digit forces zero extend > by making it 1 bit bigger before determining the type, thereby ensuring a zero > value high bit when the literal has a leading zero. That seems quite a natural > thing to do as well. Obviously more work is needed on specifying that behaviour > but I am still happy with the concept. I guess if the leading zero rule was > dropped the only thing to be lost is the ability to create short literals less > that 255. Thoughts? Binary literals and unsigned int literals enhance productivity by letting you 'write what you mean'. I see no value in inferring the type of a literal, triggered by the 'u' suffix or not. There will come a day when someone submits a bug claiming overload resolution is broken because they're passing 0x007fu and think the byte overloading should be selected rather than int. They'll be wrong, but it costs money to tell them that. But this is Joe's project so pay no attention to me :-) Alex From winson at atypon.com Thu Jul 2 13:04:04 2009 From: winson at atypon.com (Winson Quock) Date: Thu, 2 Jul 2009 13:04:04 -0700 Subject: Proposal: Elvis and Other Null-Safe Operators Message-ID: Hi, I would like to add one small addition to this proposal, if it is not too late. Null-safe for-each loop: List strings = null; // could be null for (String s : string) { // if list or array is null, do not throw NPE but skip the loop ... } ADVANTAGE: This replace the current cumbersome and often forgot checks if (string != null) { for (String s : string) { // if list or array is null, do not throw NPE but skip the loop ... } } COMPATIBILITY: This is generally backward compatibility except perhaps some very arcane codes depending on the throwing of NPE to function correctly, like int totalLen = 0; try { for (String s : string) { // if list or array is null, do not throw NPE but skip the loop totalLen += s.length(); } } catch (NullPointerException e) { totalLength = -1; } Such practices should be exceeding rare and should not be a concern, or we can introduce a -X compiler option to restore the original behavior. ALTERNATIVE: Use a new '?:' operator for null-safe loop, similar to those other operators proposed by this proposal for (String s ?: string) { // if list or array is null, do not throw NPE but skip the loop ... } This alleviates the compatibility issue with the arcane case above. From Joe.Darcy at Sun.COM Mon Jul 6 09:42:45 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 06 Jul 2009 09:42:45 -0700 Subject: Proposal: Elvis and Other Null-Safe Operators In-Reply-To: References: Message-ID: <4A522985.7010502@sun.com> If the existing gamut of null-safe operators are added, they could be used before the for-each loop to guard against null; the for-loop itself does not need to change. -Joe Winson Quock wrote: > Hi, > > I would like to add one small addition to this proposal, if it is not too > late. > > Null-safe for-each loop: > > List strings = null; // could be null > for (String s : string) { // if list or array is null, do not throw NPE but > skip the loop > ... > } > > ADVANTAGE: > > This replace the current cumbersome and often forgot checks > > if (string != null) { > for (String s : string) { // if list or array is null, do not throw NPE > but skip the loop > ... > } > } > > COMPATIBILITY: This is generally backward compatibility except perhaps some > very arcane codes depending on the throwing of NPE to function correctly, > like > > int totalLen = 0; > try { > for (String s : string) { // if list or array is null, do not throw NPE > but skip the loop > totalLen += s.length(); > } > } catch (NullPointerException e) { > totalLength = -1; > } > > Such practices should be exceeding rare and should not be a concern, or we > can introduce a -X compiler option to restore the original behavior. > > ALTERNATIVE: Use a new '?:' operator for null-safe loop, similar to those > other operators proposed by this proposal > > for (String s ?: string) { // if list or array is null, do not throw NPE but > skip the loop > ... > } > > This alleviates the compatibility issue with the arcane case above. > > From Thomas.Hawtin at Sun.COM Mon Jul 6 09:51:15 2009 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 06 Jul 2009 17:51:15 +0100 Subject: Proposal: Elvis and Other Null-Safe Operators In-Reply-To: References: Message-ID: <4A522B83.2090905@sun.com> Winson Quock wrote: > This replace the current cumbersome and often forgot checks > > if (string != null) { > for (String s : string) { // if list or array is null, do not throw NPE > but skip the loop > ... > } > } Note, you can do this in a more source-friendly way with a little helper method: for (String s : maybe(string)) { ... } where wrapNull is something along the lines of: public static Iterable maybe(Iterable iterable) { return iterable==null ? Collections.emptyList() : iterable; } For arrays (can we get away for reference arrays, plz?) public static Iterable maybe(E[] array) { return array==null ? Collections.emptyList() : Arrays.asList(array); } I believe @Nonnull will help with forgetful programmers. Usual advice applies to avoid nulls, particularly as substitutes for empty collections. Tom Hawtin From Joe.Darcy at Sun.COM Wed Jul 15 14:22:32 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 15 Jul 2009 14:22:32 -0700 Subject: Combined grammar changes for binary literals and underscores in literals Message-ID: <4A5E4898.5000708@sun.com> Hello. Getting around to some grammatical hacking, below is a grammar I think properly captures the desired changes for combining the binary literals and underscores in literals proposals. This grammar does *not* include support for unsigned literals or autosizing literals. The basic approach is to redefine the FooDigits productions to be a non-empty sequence of Foo digits and underscores starting and ending with a Foo digit rather than just a non-empty sequence Foo digits. Each FooDigits nonterminal has two rules, one for a single digit and one for two or more digits. The rules for two or more digits force a true digit, rather than an underscore, as the first and last character. Changing the FooDigits definitions allows underscores in both integer and floating-point literals. In more detail: * Replace the productions Digits, HexDigits, OctalDigits, and in JLSv3 3.10.1 as shown below * Add productions for BinaryDigits * Add rules for FooDigitsAndUnderscores and FooDigitOrUnderscore * Add productions to DecimalNumeral and OctalNumeral: * Add a rule for Underscores IntegerLiteral: DecimalIntegerLiteral HexIntegerLiteral OctalIntegerLiteral BinaryIntegerLiteral // New BinaryIntegerLiteral: BinaryNumeral IntegerTypeSuffix_opt BinaryNumeral: 0 b BinaryDigits 0 B BinaryDigits DecimalNumeral 0 NonZeroDigit Digits_opt NonZeroDigit Underscores Digits // New Underscores _ Underscores _ Digits: Digit Digit DigitsAndUnderscores Digit DigitsAndUnderscores: DigitOrUnderscore DigitsAndUnderscores DigitOrUnderscore DigitOrUnderscore Digit _ HexDigits: HexDigit HexDigit HexDigitsAndUnderscores HexDigit HexDigitsAndUnderscores: HexDigitOrUnderscore HexDigitsAndUnderscores HexDigitOrUnderscore HexDigitOrUnderscore HexDigit _ OctalNumeral: 0 OctalDigits 0 Underscores OctalDigits // New OctalDigits: OctalDigit OctalDigit OctalDigitsAndUnderscores OctalDigit OctalDigitsAndUnderscores: OctalDigitOrUnderscore OctalDigitsAndUnderscores OctalDigitOrUnderscore OctalDigitOrUnderscore OctalDigit _ BinaryDigits: BinaryDigit BinaryDigit BinaryDigitsAndUnderscores BinaryDigit BinaryDigitsAndUnderscores: BinaryDigitOrUnderscore BinaryDigitsAndUnderscores BinaryDigitOrUnderscore BinaryDigitOrUnderscore BinaryDigit _ BinaryDigit: one of 0 1 -Joe From vimilsaju at yahoo.com Wed Jul 15 15:33:45 2009 From: vimilsaju at yahoo.com (Vimil Saju) Date: Wed, 15 Jul 2009 15:33:45 -0700 (PDT) Subject: Regarding null safe oprators Message-ID: <984045.87784.qm@web51304.mail.re2.yahoo.com> If null-safe operators are going to be a part of JDK-7, is it possible to modify the new 'for loop' syntax so that a null pointer exception is not thrown if the list or array over which the loop iterates is null? Currently the below code will throw a NPE because integerList is null. List<Integer> integerList = null; for(Integer i: integerList) { } From lk at teamten.com Wed Jul 15 15:39:50 2009 From: lk at teamten.com (Lawrence Kesteloot) Date: Wed, 15 Jul 2009 15:39:50 -0700 Subject: Regarding null safe oprators In-Reply-To: <984045.87784.qm@web51304.mail.re2.yahoo.com> References: <984045.87784.qm@web51304.mail.re2.yahoo.com> Message-ID: <997cab100907151539l3bcb0c68o4773986a7166dc44@mail.gmail.com> I think that your code below should throw an NPE. An empty list is not the same as a null list. But you could argue that a new syntax would allow it, like "for (Integer i ?: integerList)". (I would vote against this too, but only for simplicity, not because it's the wrong behavior.) Lawrence On Wed, Jul 15, 2009 at 3:33 PM, Vimil Saju wrote: > If null-safe operators are going to be a part of JDK-7, is it possible to modify the new 'for loop' syntax so that a null pointer exception is not thrown if the list or array over which the loop iterates is null? > > Currently the below code will throw a NPE because integerList is null. > > List integerList = null; > for(Integer i: integerList) { > > } > > > > > From Joe.Darcy at Sun.COM Wed Jul 15 16:06:43 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 15 Jul 2009 16:06:43 -0700 Subject: Regarding null safe oprators In-Reply-To: <984045.87784.qm@web51304.mail.re2.yahoo.com> References: <984045.87784.qm@web51304.mail.re2.yahoo.com> Message-ID: <4A5E6103.1030805@sun.com> Vimil Saju wrote: > If null-safe operators are going to be a part of JDK-7, is it possible to modify the new 'for loop' syntax so that a null pointer exception is not thrown if the list or array over which the loop iterates is null? > No; that will not be done if null-safe operators are added. -Joe From i30817 at gmail.com Wed Jul 15 16:45:36 2009 From: i30817 at gmail.com (Paulo Levi) Date: Thu, 16 Jul 2009 00:45:36 +0100 Subject: A simple solution for [] access that can trivially be added to List and Map. Message-ID: <212322090907151645s3766f123w184ef95e904b1c13@mail.gmail.com> Just speaking out, me a "normal" java programmer, don't really care about []. I like the idea of extension methods much more especially if they can't be invoked directly, since, they can serve as a bridge between a hypothetical java 7 and a hypothetical java 8 with the extended interfaces (List, CharSequence etc), so that then, those extensions methods become no-ops. Also could you please make a super-interface of both StringBuilder and StringBuffer? There are lot of places on the jdk using StringBuffer when they should use StringBuilder, but can't be changed because they are public methods. From i30817 at gmail.com Wed Jul 15 16:49:24 2009 From: i30817 at gmail.com (Paulo Levi) Date: Thu, 16 Jul 2009 00:49:24 +0100 Subject: Regarding null safe oprators Message-ID: <212322090907151649q239c5328p7807a6eec94c3bb@mail.gmail.com> Someone on another message on this very topic sent this method: public static Iterable maybe(Iterable iterable) { return iterable == null ? Collections.emptyList() : iterable; } used like this: for(String s : maybe(list)){ ... } Me i consider a null list a bug. From Joe.Darcy at Sun.COM Wed Jul 15 16:57:21 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 15 Jul 2009 16:57:21 -0700 Subject: Thoughts on unified integer literal improvements In-Reply-To: <4A49B80B.3080704@sun.com> References: <4A1DC533.2060202@sun.com> <4A488FE5.60309@sun.com> <1246328700.4a49777c21249@www.paradise.net.nz> <4A497AEA.5090803@sun.com> <4A49AF0E.3010202@paradise.net.nz> <4A49B80B.3080704@sun.com> Message-ID: <4A5E6CE1.3050005@sun.com> Weijun Wang wrote: > Bruce Chapman wrote: > >> Weijun Wang wrote: >> >>> brucechapman at paradise.net.nz wrote: >>> >>> >>>> Quoting Weijun Wang : >>>> >>>> >>>> >>>>>> long ell = 0xFFFFFFFFu; // A positive long value >>>>>> >>>>>> >>>>> Any particular requirement here? Why not simply >>>>> >>>>> long ell = 0xFFFFFFFFl; >>>>> >>>>> >>>>> >>>>>> I think this approach has some advantages over the "y" suffix; in >>>>>> particular I think it gives more desirable behavior in cases like >>>>>> >>>>>> >>>>> this: >>>>> >>>>> >>>>>> byte b = 0xFFy // a negative byte value >>>>>> byte b = 0xFFu // also a negative byte value >>>>>> >>>>>> short s = 0xFFy // a negative short value, -128; >>>>>> // byte value is signed extended >>>>>> short s = 0xFFu // a positive short value, +127 >>>>>> >>>>>> int i = 0xFFy // -128 >>>>>> int i = 0xFFu // 127 >>>>>> >>>>>> >>>>> Does this mean the actual value of 0xFFu is determined by looking at >>>>> the >>>>> LHS of the assignment? This is terrible. >>>>> >>>>> >>>> Yes that would be terrible if it were true, fortunately it is not. The value is >>>> determined by the digits and any radix specified by the prefix. In the above >>>> examples, the "y" suffix means byte, so when is widened to a short or int it >>>> sign extends and stays negative. The "u" suffix would create a special type that >>>> would always zero extend when widening giving a positive number. >>>> >>>> >>> I still find it difficult to understand this 'u' thing. When you say >>> "zero extend when", isn't that the same with what I said "depending on >>> the LHS"? >>> >>> >> No, The JLS defines a number of conversions, one of which is widening >> and when that occurs. For example >> >> byte b = 1; >> >> int j = b+1; >> >> in the second line the type of the expression "b+1" is not determined by >> the LHS, but the various conversion rules say that the b expression of >> type byte must be widened to an int before the addition and assignment >> occur in that order. >> >> >> Similarly when we say >> >> short s = 0xFFu; >> >> What is happening is that the type of the expression on the right has >> some conversions applied before the assignment. Collectively those are >> called assignment conversion, and when 0xFFu has a type of byte, then >> the particular assignment conversion which is applied is the widening >> conversion. >> > > I somehow understand your point. This 0xFFu is a brand new data type. > Not it is not; it is a more concise notation for expressing various constants more convenient. > Don't know if it can be coined without any new VM bytecode. Implementing > In two's complement arithmetic, add, subtract, and multiply give the same bit-level results for a signed and unsigned interpretation of the data. For the basic operations, only a separate divide method would be needed. There is no need for a new bytecode to support unsigned literals. -Joe From reinier at zwitserloot.com Wed Jul 15 18:00:43 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 16 Jul 2009 03:00:43 +0200 Subject: Regarding null safe oprators In-Reply-To: <212322090907151649q239c5328p7807a6eec94c3bb@mail.gmail.com> References: <212322090907151649q239c5328p7807a6eec94c3bb@mail.gmail.com> Message-ID: <5582C3B3-BE40-48D0-98D2-24A6F9B05454@zwitserloot.com> Amen; null lists are a mistake (or at least, if you try to treat them as an actual list). A 'maybe' utility method as Paulo Levi showed is more than sufficient to address the use case. One could make a case for adding this to java.util.Collections. --Reinier Zwitserloot On 2009/16/07, at 01:49, Paulo Levi wrote: > Someone on another message on this very topic sent this method: > public static Iterable maybe(Iterable iterable) { > return iterable == null ? Collections.emptyList() : > iterable; > } > used like this: > for(String s : maybe(list)){ > ... > } > > Me i consider a null list a bug. > From Joe.Darcy at Sun.COM Wed Jul 15 18:46:32 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 15 Jul 2009 18:46:32 -0700 Subject: Thoughts on unified integer literal improvements In-Reply-To: <4A488594.2010000@paradise.net.nz> References: <4A1DC533.2060202@sun.com> <4A488594.2010000@paradise.net.nz> Message-ID: <4A5E8678.8020805@sun.com> Catching up on email... Bruce Chapman wrote: > Joe Darcy wrote: >> Hello. >> >> On the set of improved integer literal features, I think combining >> the underscores as separators and binary literals is straightforward >> given separately correct grammars for each change. >> >> As an alternate to "y" and "s" suffices, I suggesting considering a >> "u" suffix to mean unsigned. Literals with a trailing "u" would have >> type int; widening conversions of such literals would 0 extend and >> narrowing conversions would range check on the width of set bits. >> For example, >> > All, > > I have spent some time considering Joe's suggestions. > > While I really like the aesthetics of "u" means "unsigned" compared > with "y" suffix for "byte", I am also aware of the considerable extra > complexity of defining a new primitive type in the JLS. From a first > scan I have identified the most obvious change points which are > recorded in the google document > http://docs.google.com/View?id=dcvp3mkv_112567xb4n Hi Bruce. Thanks for starting a more detailed analysis and comparison of the "u" and "y" proposals. Let's see, from the top in 3.10.1 "u" and "U" can be added to the list of Integer Type Suffixes with some explanatory text like: "An integer literal is of type int if it is suffixed with "u" or "U"; the trailing "u" or "U" indicates an unsigned conversion process occurs. Unsigned literals are converted as if int were an unsigned 32-bit 2's complement format and different widening and narrowing primitive conversion rules are applied to unsigned literals. For example, 2147483648u (2^31) is equal to -2147483648 and 2147483649u (2^31 + 1) is equal to -2147483647." In terms of conversions, there are 11 categories of conversions and 5 conversion contexts. In 5.1.2, there could be three new widening primitive conversions: Unsigned int literal to long, float, or double with appropriate rules to preserve the sign of the result: "A widening conversion of an unsigned int literal to long zero-extends the converted int value; meaning the low-order 32-bits of the long are equal to the int value and the high-order 32-bits of the long are zero. Widening conversion of an unsigned int to float or double acts as if the value first went through a widening conversion of unsigned int to long and then a widening conversion of long to float or double, respectively." And in 5.1.3, there could be three new narrowing primitive conversions: Usigned int to byte, short, or char These would actually be the same as the current narrowing conversions on int; just grab the low-order n bits. The real help would come in section 5.2, Assignment Conversion, to redefine what "a constant expression is representable in the type of the variable" for unsigned literals to allow things like "byte b = 0xFFu;" The text of the method invocation conversion would remain unchanged; with the defined widening conversion, given the method declaration public void foo(long ell) { System.out.println(ell);} the call foo(0xFFFFFFFFu) would do the right thing, print out 4294967295. Narrowing conversions do not take place in a method invocation context. So to call public void bar(byte b) {...} the call bar(0xFFu) // no bar(int) would not work, but bar((byte)0xFFu) would. Unary numeric promotion (5.6.1) is not affected by unsigned literals since only values narrowing than int are promoted. Given the earlier definitions of widening primitive conversion, I don't think any explicit changes are needed in binary numeric promotion (5.6.2). There are some potential puzzlers here. Since 2's complement divide doesn't give the same bit-wise result for divide, unlike for add, subtract, and multiply "unsignedLiteral1 / unsignedLiteral2" may give a surprising answer and should be a compiler warning. Another limitation of this proposal is that only unsigned literals are regarded as unsigned. There is no analogy of an "unsigned expression" to parallel a "constant expression" (15.28). That means long value1 = 0xFFFFFFFFu; long value2 = 0xFFFFFFFEu + 1u; will give different results. It would be possible to define a subset of the constant expressions to be unsigned constant expressions (starting with unsigned literals, operation on them with unary operations, binary +, -, and * (but not / ), shifts, bitwise logical operations, etc.). Perhaps unsigned constant expression would need to be defined to reduce the "gotcha" factor of some of the current results. -Joe From dierk.koenig at canoo.com Thu Jul 16 03:13:28 2009 From: dierk.koenig at canoo.com (=?ISO-8859-1?Q?Dierk_K=F6nig?=) Date: Thu, 16 Jul 2009 12:13:28 +0200 Subject: Elvis operator In-Reply-To: <4A5E6103.1030805@sun.com> References: <984045.87784.qm@web51304.mail.re2.yahoo.com> <4A5E6103.1030805@sun.com> Message-ID: <0E72FCCD-14E8-4FF3-BA8A-11A94A6DD5E8@canoo.com> Hi, I made the term "Elvis operator" popular through the "Groovy in Action" and I would like to clarify its meaning because it is often confused with the "Null-safe dereferencing operator". This has led to numerous misquotes in communications, conference talks, and podcasts like in episode 253 of the JavaPosse. The Elvis operator is a shortcut for the ternary "if" operator when the "true" case should yield the value of the conditional. The following lines are equivalent(1) in Groovy if (a) then a else b // classic if a ? a : b // ternary if a ?: b // Elvis This construction only makes sense in Groovy because "a" can be of any arbitrary type - and is not restricted to be a boolean expression. The boolean value inside the conditional is calculated by the rules of the "Groovy truth", where objects can be casted to boolean such that e.g. null objects are treated as "false" just like empty Strings, Maps, and Lists. Therefore, an Elvis expression does not necessarily return a boolean in Groovy but can be of any runtime type allowing constructions like String s = a ?: "n/a" to set a reference to a default value if no proper value is available. The same use comes handy in method calls like myMethod( a ?: "n/a" ) The discussion above makes me think that an Elvis operator would be much less useful in Java... Elvis is often confused with the null-safe dereferencing of objects like in a?.foo() which does not throw NPE if "a" is null but returns null without evaluating foo(). This is __**NOT**__ an Elvis operator unless you assume a one-eyed Elvis !!! I'm glad to see that in recent posts on this list, the distinction has much improved. all the best Dierk (1) "equivalent" does not mean "identical" because in case of the Elvis operator, the "a" expression is only evaluated once. P.S. Needless to say: there is only one true Elvis! From Alex.Buckley at Sun.COM Thu Jul 16 11:35:11 2009 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Thu, 16 Jul 2009 11:35:11 -0700 Subject: Elvis operator Message-ID: <4A5F72DF.1010506@sun.com> Dierk, Thank you very much for writing. Putting ?: and ?. side-by-side shows they are dual in a type-theoretic sense. ?: returns a specific value of a specific type (indicating a default), while ?. returns a non-value of the bottom type. Since the bottom type is a subtype of all other types, the non-value will swallow all messages sent to it. The non-value turns into the null reference at assignment conversion or method invocation conversion, of course. Turning to more practical matters, do you have a sense of how often ?. is used in Groovy code? Why would anyone dereference with '.' when they could use '?.' ? If '.' is still commonly used, is Groovy code littered with as many == comparisons with null as Java code is? Alex From reinier at zwitserloot.com Thu Jul 16 17:24:45 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 17 Jul 2009 02:24:45 +0200 Subject: Elvis operator In-Reply-To: <4A5F72DF.1010506@sun.com> References: <4A5F72DF.1010506@sun.com> Message-ID: <07E6FCFD-BEFB-4636-9259-A3DACDCAB6F8@zwitserloot.com> You couldn't use ?. for any method that returned a primitive type (unless we expect ?. to mean: returns the default (0/false/'\0') primitive if the LHS is null, which sounds like a bad idea to me), for starters. Also, often the act of calling the method is not optional, and if at that point the LHS is indeed null, then an NPE would be the correct action. ?. is great stuff when you need to do what it says on the tin: let the expression evaluate to null if the LHS is null (which implies that the LHS being null is a common and expected possibility). Using ?. instead of . as some sort of safety mechanism is bass ackwards. In other words, '.' should be the norm, and ?. should be used only after you realize that it the circumstance calls for its use. For example, when the LHS being null is an unexpected possibility, using ?. just moves the problem forward time a little bit; things are very likely going to go wrong soon anyway. However, when they go wrong, they either go wrong without throwing an exception, making it harder to figure out there's a problem, and if you do get an exception, the methods mentioned in the stack trace are now even less related to the source of the problem. As an aside, I saw this trick in the javac core code: param.getClass(); //NPE which is a much shorter way of writing: if ( param == null ) throw new NullPointerException("param"); And I appear to be in the minority as I think the above (without any braces) is perfectly fine, readable, maintainable, properly styled code. You do miss the ability to name the problem (NPEs thrown by the runtime don't have a message), and you should definitely comment it, as by itself it looks kind of funky. getClass() is just a randomly selected method that has no side effects and is fast. --Reinier Zwitserloot On 2009/16/07, at 20:35, Alex Buckley wrote: > Dierk, > > Thank you very much for writing. > > Putting ?: and ?. side-by-side shows they are dual in a type-theoretic > sense. ?: returns a specific value of a specific type (indicating a > default), while ?. returns a non-value of the bottom type. Since the > bottom type is a subtype of all other types, the non-value will > swallow > all messages sent to it. The non-value turns into the null reference > at > assignment conversion or method invocation conversion, of course. > > Turning to more practical matters, do you have a sense of how often ?. > is used in Groovy code? Why would anyone dereference with '.' when > they > could use '?.' ? If '.' is still commonly used, is Groovy code > littered > with as many == comparisons with null as Java code is? > > Alex > From Alex.Buckley at Sun.COM Thu Jul 16 17:43:27 2009 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Thu, 16 Jul 2009 17:43:27 -0700 Subject: Elvis operator In-Reply-To: <07E6FCFD-BEFB-4636-9259-A3DACDCAB6F8@zwitserloot.com> References: <4A5F72DF.1010506@sun.com> <07E6FCFD-BEFB-4636-9259-A3DACDCAB6F8@zwitserloot.com> Message-ID: <4A5FC92F.9050008@sun.com> Reinier Zwitserloot wrote: > You couldn't use ?. for any method that returned a primitive type > For example, when the LHS being null is an unexpected possibility, using > ?. just moves the problem forward time a little bit; things are very > likely going to go wrong soon anyway. However, when they go wrong, they > either go wrong without throwing an exception, making it harder to > figure out there's a problem, and if you do get an exception, the > methods mentioned in the stack trace are now even less related to the > source of the problem. These are exactly the reasons why I'm not a fan of ?. for Java. Dierk actually wrote to me directly and explained how idiomatic Groovy code has a role for . and a role for ?. - I hope he will not mind me quoting a little: "If m is a Map, then in Groovy you can refer to the value of key "k" in m as m.k and since that returns null for unknown keys, you often find Elvis as m.k?.foo() in those usages ... you _don't_ write m?.k?.foo() because if m == null you have an ultimate programming error and want NPE to be thrown." (BTW, saying 'LHS' is a bit confusing because LHS typically alludes to the assignment (or method invocation) context ... saying 'receiver' isn't quite right either, since the expression may not be a method invocation ... 'Primary' is probably best, see JLS 15.8.) Alex From dierk.koenig at canoo.com Fri Jul 17 00:31:40 2009 From: dierk.koenig at canoo.com (=?ISO-8859-1?Q?Dierk_K=F6nig?=) Date: Fri, 17 Jul 2009 09:31:40 +0200 Subject: Fwd: Elvis operator References: <3382A24D-720D-483E-94A5-F607D79D827A@canoo.com> Message-ID: <651F121D-0FB2-425D-BB9F-D9C4F26E662B@canoo.com> for everybodies information > Von: Dierk K?nig > Datum: 16. Juli 2009 22:32:04 GMT+02:00 > An: Alex Buckley > Betreff: Re: Elvis operator > > Hi Alex, > > thanks a lot for your insight and questions. > >> Putting ?: and ?. side-by-side shows they are dual in a type- >> theoretic >> sense. ?: returns a specific value of a specific type (indicating a >> default), while ?. returns a non-value of the bottom type. >> Since the >> bottom type is a subtype of all other types, the non-value will >> swallow >> all messages sent to it. The non-value turns into the null >> reference at >> assignment conversion or method invocation conversion, of course. > > Well, from the effect you are describing, I don't quite see the > "duality". > > However, even assuming it is there, it would still be no good reason > to also call ?. Elvis. It would only be confusing. > Call it Jacko, if you will (but then I would write the operator /. to > indicate the tilted hat that only reveals one eye). > >> Turning to more practical matters, do you have a sense of how >> often ?. >> is used in Groovy code? > > There are places, where it is often used, e.g. in GSPs (Groovy > Server Pages > as used in Grails). This is a special case of access to Maps as the > model > that is given from the controller to the view is a Map. > If m is a Map, then in Groovy you can refer to the value of key "k" > in m as > m.k > and since that returns null for unknown keys, you often find Elvis as > m.k?.foo() > in those usages. > >> Why would anyone dereference with '.' when they >> could use '?.' ? > > because you often want NPE to be thrown for the sake of failing early. > In the example above, you _don't_ write > m?.k?.foo() > because if m == null you have an ultimate programming error and want > NPE to be thrown. > >> If '.' is still commonly used, is Groovy code littered >> with as many == comparisons with null as Java code is? > > Not at all. Groovy idiomatic code has very few null checks. > The exceptional case where you need those has to do with > the Groovy truth. You sometimes want to distinguish e.g. between > a String being null and a String being empty. > > cheers > Dierk > > From dierk.koenig at canoo.com Fri Jul 17 00:32:39 2009 From: dierk.koenig at canoo.com (=?ISO-8859-1?Q?Dierk_K=F6nig?=) Date: Fri, 17 Jul 2009 09:32:39 +0200 Subject: Fwd: Elvis operator References: <5623CB5C-C149-4F66-B897-A93CB2E0125E@canoo.com> Message-ID: <758472E6-B58F-477F-AC54-050EAF3CB0FF@canoo.com> for everybodies information > Von: Dierk K?nig > Datum: 17. Juli 2009 09:13:44 GMT+02:00 > An: Alex Buckley > Betreff: Re: Elvis operator > > > Am 16.07.2009 um 23:31 schrieb Alex Buckley: >> >> Oh sure. I wasn't suggesting ?. should be called Elvis; quite the >> opposite. I was seeing that Elvis (?:) is as distinct as can be >> from the other operator (?.). > > Ok. Good to see we are on the same page here. > Sorry for misinterpreting your statement. > >> >>>> Turning to more practical matters, do you have a sense of how often >>>> ?. is used in Groovy code? >>> There are places, where it is often used, e.g. in GSPs (Groovy >>> Server >>> Pages as used in Grails). This is a special case of access to Maps >>> as >>> the model that is given from the controller to the view is a Map. If >>> m is a Map, then in Groovy you can refer to the value of key "k" >>> in m >>> as m.k and since that returns null for unknown keys, you often find >>> Elvis as m.k?.foo() in those usages. >> >> Very interesting. This and probably other Groovy idioms that >> exploit ?. are exactly why I'm not a fan of it for Java, where the >> idioms simply don't apply. > > I agree that it is much less useful in Java (this applies to a much > bigger extend to the Elvis operator). > >> >>>> Why would anyone dereference with '.' when they could use '?.' ? >>> because you often want NPE to be thrown for the sake of failing >>> early. In the example above, you _don't_ write m?.k?.foo() because >>> if >>> m == null you have an ultimate programming error and want NPE to be >>> thrown. >>>> If '.' is still commonly used, is Groovy code littered with as many >>>> == comparisons with null as Java code is? >>> Not at all. Groovy idiomatic code has very few null checks. The >>> exceptional case where you need those has to do with the Groovy >>> truth. You sometimes want to distinguish e.g. between a String being >>> null and a String being empty. >> >> It sounds like an NPE from an "ultimate programming error" is, >> somehow, a little more 'acceptable' in Groovy than in Java. I >> hesitate to say that, but I am trying to reconcile "very few null >> checks" with your clear indication that NPE is sometimes desired. > > If you follow the style of programming that no NPE must be thrown > whatsoever, then you are right. > But I find that not practical - neither in Java nor Groovy. > I don't want NPEs to be thrown because of lacking data, bad user > input, missing files, and the likes > but I _do_ want them to be thrown when they reveal a programming > error, i.e. the programmer has > assumed that this reference cannot be null - but d'oh! - it is. > This NPE may still be caught at an upper level to not destroy the > user experience but the indication > should be available be it for logging or else. This needs to include > the stacktrace. > > Using x?.foo() instead means: Yes, I know that x may be null, in > which case I'm happy > to not do foo() at all and return null. > > Of course (a like mentioned in other posts) this feature can be > carelessly overused. Using > x?.foo() when trailing code actually relies on foo() being executed > would be wrong. > The Groovy solution to this is preceding your code with the > precondition > assert x > that throws an AssertionError if x does not evaluate to true in the > sense of the Groovy truth. > BTW: Groovy asserts are always enabled and give detailed error > messages about > the offending expression and the values of each contained variable. > > Fazit: this may well fall into the category of "very useful in > Groovy, less so in Java". > > all the best > Dierk From Joe.Darcy at Sun.COM Fri Jul 17 11:39:38 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 17 Jul 2009 11:39:38 -0700 Subject: Elvis operator In-Reply-To: <4A5F72DF.1010506@sun.com> References: <4A5F72DF.1010506@sun.com> Message-ID: <4A60C56A.8060504@sun.com> Alex Buckley wrote: > Dierk, > > Thank you very much for writing. > Yes, thank you for providing history and context about Elvis in Groovy. -Joe From dierk.koenig at canoo.com Fri Jul 17 12:07:39 2009 From: dierk.koenig at canoo.com (=?ISO-8859-1?Q?Dierk_K=F6nig?=) Date: Fri, 17 Jul 2009 21:07:39 +0200 Subject: Elvis operator In-Reply-To: <4A60C56A.8060504@sun.com> References: <4A5F72DF.1010506@sun.com> <4A60C56A.8060504@sun.com> Message-ID: <6D06476C-DEA7-48BB-A4B5-165E83877A4A@canoo.com> your welcome all the best for proceeding with project coin Dierk Am 17.07.2009 um 20:39 schrieb Joseph D. Darcy: > Alex Buckley wrote: >> Dierk, >> >> Thank you very much for writing. >> > > Yes, thank you for providing history and context about Elvis in > Groovy. > > -Joe From gkbrown at mac.com Mon Jul 20 13:09:08 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 16:09:08 -0400 Subject: For further consideration, round 2 Message-ID: Hi all, I just came across this thread and wanted to comment: http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001945.html Hope I'm not too late. > 6,7 (Elvis and Other Null-Safe Operators, Indexing access syntax for > Lists and Maps) > 8,9, Strings in switch, Collection Literals. IMO, the Elvis operator would be handy, though definitely not a must have. Same goes for Strings in switch statements. My main interest is in the other two items: "Indexing access syntax for Lists and Maps" and "Collection Literals". 1) Indexing access syntax for Lists and Maps It would be nice to see this feature extended to any class, not just List and Map. Groovy supports this by mapping the index operator to getAt() and putAt() - a similar approach (possibly one that maps to get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and would still work for List and Map. 2) Collection Literals I would argue that, since List, Map, and Set are not part of java.lang, they should not be given special language-level treatment. Also, I don't like the ambiguity of what type of collection is actually created. Finally, I'm not sure I see a strong enough use case here to justify a language change. Why not just add some new varargs methods to meet this need? List and Set would be easy: List list = ArrayList.unmodifiableList(1, 2, 3); Set set = HashSet.unmodifiableSet("a", "b", "c"); The resulting code is fairly concise, doesn't require any language changes, and eliminates any ambiguity about what type of collection is created. Map would require a bit more effort since there is currently no class to represent a key/value pair, but could work something like this: Map map = HashMap.unmodifiableMap(new Map.Pair("foo", 123), new Map.Pair("bar", 456)); A language extension for pairs might make sense, if Pair was defined in java.lang and the rules for type inference could be extended to support it: Map map = HashMap.unmodifiableMap({"foo":123}, {"bar": 456}); But again, is there really a strong enough use case for collection literals in Java to justify any kind of language change? If you are finding that you truly need collection literals, is it possible that Java just isn't the right language for the problem you are trying to solve? -Greg From neal at gafter.com Mon Jul 20 13:18:41 2009 From: neal at gafter.com (Neal Gafter) Date: Mon, 20 Jul 2009 13:18:41 -0700 Subject: For further consideration, round 2 In-Reply-To: References: Message-ID: <15e8b9d20907201318p3f23cf1do71507c391eb8e9eb@mail.gmail.com> On Mon, Jul 20, 2009 at 1:09 PM, Greg Brown wrote: > But again, is there really a strong enough use case for collection > literals in Java to justify any kind of language change? If you are > finding that you truly need collection literals, is it possible that > Java just isn't the right language for the problem you are trying to > solve? I won't attempt to defend the collection literal proposal in particular, but I will point out that different parts of a program can stress different parts of your programming language. It just isn't reasonable to switch among languages for different parts of a project. Cheers, Neal From gkbrown at mac.com Mon Jul 20 13:26:13 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 16:26:13 -0400 Subject: For further consideration, round 2 In-Reply-To: <15e8b9d20907201318p3f23cf1do71507c391eb8e9eb@mail.gmail.com> References: <15e8b9d20907201318p3f23cf1do71507c391eb8e9eb@mail.gmail.com> Message-ID: <39468512-D623-466C-A10B-83FF762B6EA9@mac.com> > I won't attempt to defend the collection literal proposal in > particular, but I will point out that different parts of a program > can stress different parts of your programming language. I agree that it is ideal to keep language sprawl on any given project to a minimum. However, some languages are simply better suited to certain tasks than others. Why not take advantage of it? Isn't that one of the reasons for adding multi-language support to the JVM? > It just isn't reasonable to switch among languages for different > parts of a project. I would suggest that many (most?) real-world projects do switch between languages, and often. A typical web project may use HTML, CSS, JavaScript, Java, JSP, XML, SQL, etc. This isn't necessarily a good example of it, but I would say there is definitely an argument to be made for using "the right tool for the job". From gkbrown at mac.com Mon Jul 20 13:45:11 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 16:45:11 -0400 Subject: For further consideration, round 2 In-Reply-To: References: Message-ID: > Map would require a bit more effort since there is currently > no class to represent a key/value pair, but could work something like > this: > > Map map = HashMap.unmodifiableMap(new > Map.Pair("foo", 123), > new Map.Pair("bar", 456)); After doing some quick prototyping, it appears that at least one minor language change would help facilitate this approach. The above code generates a compiler warning: "Type safety : A generic array of Map.Pair is created for a varargs parameter" One way to eliminate this warning would be to make the contents of the varargs array immutable (or at least, optionally so). How about defining "final" to also extend to the array contents when applied to varargs? public static Map unmodifiableMap(final Pair... pairs) {...} (FYI, I have no idea how feasible this is - just brainstorming) Greg From Joe.Darcy at Sun.COM Mon Jul 20 13:54:03 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 20 Jul 2009 13:54:03 -0700 Subject: For further consideration, round 2 In-Reply-To: References: Message-ID: <4A64D96B.5010102@sun.com> Greg Brown wrote: >> Map would require a bit more effort since there is currently >> no class to represent a key/value pair, but could work something like >> this: >> >> Map map = HashMap.unmodifiableMap(new >> Map.Pair("foo", 123), >> new Map.Pair("bar", 456)); >> > > After doing some quick prototyping, it appears that at least one minor > language change would help facilitate this approach. The above code > generates a compiler warning: > > "Type safety : A generic array of Map.Pair is created > for a varargs parameter" > > One way to eliminate this warning would be to make the contents of the > varargs array immutable (or at least, optionally so). How about > defining "final" to also extend to the array contents when applied to > varargs? > > public static Map unmodifiableMap(final Pair... > pairs) {...} > > (FYI, I have no idea how feasible this is - just brainstorming) > No, that approach is not feasible for Project Coin; Bob Lee's "Simplified Varargs Method Invocation" (http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000217.html) is intended to address exactly this problem. -Joe From reinier at zwitserloot.com Mon Jul 20 13:54:59 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 20 Jul 2009 22:54:59 +0200 Subject: For further consideration, round 2 In-Reply-To: References: Message-ID: <3E5800CD-3807-4F05-AB42-5F83BB5841FE@zwitserloot.com> If "It's not in java.lang" is a valid argument, then we should get rid of the magic that makes java.io.Serializable work, as well as the foreach loops, which use java.lang.Iterable, which refers to java.util.Iterator, which is just not allowed in a java language feature, apparently. OR, we stop worrying about package names and treat proposals based on their merits, instead of pointing out irrelevant distractions. > Map map = HashMap.unmodifiableMap(new > Map.Pair("foo", 123), > new Map.Pair("bar", 456)); Just look at it. And then look at this: Map map = {"foo": 123, "bar": 456}; Now choose which one you'd rather look at, let alone type. > A language extension for pairs might make sense ... but list and map literals don't. Okay. Why? How would pairs type? A new 'java.util.Pair' type, or should it be in java.lang, which means any existing class named Pair (and, boy, are there many of those!) are now in a namespace conflict, causing fun times for everyone that imports their own Pair class via a star import? > But again, is there really a strong enough use case for collection > literals in Java to justify any kind of language change? Yes, there is. Do a code check on how many collection literals you make versus how often you do a list member lookup by index. In my code I'm looking at roughly a 50:1 ratio. --Reinier Zwitserloot On 2009/20/07, at 22:09, Greg Brown wrote: > Hi all, > > I just came across this thread and wanted to comment: > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001945.html > > Hope I'm not too late. > >> 6,7 (Elvis and Other Null-Safe Operators, Indexing access syntax for >> Lists and Maps) > >> 8,9, Strings in switch, Collection Literals. > > > IMO, the Elvis operator would be handy, though definitely not a must > have. Same goes for Strings in switch statements. My main interest is > in the other two items: "Indexing access syntax for Lists and Maps" > and "Collection Literals". > > 1) Indexing access syntax for Lists and Maps > > It would be nice to see this feature extended to any class, not just > List and Map. Groovy supports this by mapping the index operator to > getAt() and putAt() - a similar approach (possibly one that maps to > get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and > would still work for List and Map. > > 2) Collection Literals > > I would argue that, since List, Map, and Set are not part of > java.lang, they should not be given special language-level treatment. > Also, I don't like the ambiguity of what type of collection is > actually created. Finally, I'm not sure I see a strong enough use case > here to justify a language change. > > Why not just add some new varargs methods to meet this need? List and > Set would be easy: > > List list = ArrayList.unmodifiableList(1, 2, 3); > Set set = HashSet.unmodifiableSet("a", "b", "c"); > > The resulting code is fairly concise, doesn't require any language > changes, and eliminates any ambiguity about what type of collection is > created. Map would require a bit more effort since there is currently > no class to represent a key/value pair, but could work something like > this: > > Map map = HashMap.unmodifiableMap(new > Map.Pair("foo", 123), > new Map.Pair("bar", 456)); > > A language extension for pairs might make sense, if Pair was defined > in java.lang and the rules for type inference could be extended to > support it: > > Map map = HashMap.unmodifiableMap({"foo":123}, > {"bar": > 456}); > > But again, is there really a strong enough use case for collection > literals in Java to justify any kind of language change? If you are > finding that you truly need collection literals, is it possible that > Java just isn't the right language for the problem you are trying to > solve? > > -Greg > > From neal at gafter.com Mon Jul 20 13:57:18 2009 From: neal at gafter.com (Neal Gafter) Date: Mon, 20 Jul 2009 13:57:18 -0700 Subject: For further consideration, round 2 In-Reply-To: <39468512-D623-466C-A10B-83FF762B6EA9@mac.com> References: <15e8b9d20907201318p3f23cf1do71507c391eb8e9eb@mail.gmail.com> <39468512-D623-466C-A10B-83FF762B6EA9@mac.com> Message-ID: <15e8b9d20907201357r2d756a04i7b08fb43054c9587@mail.gmail.com> On Mon, Jul 20, 2009 at 1:26 PM, Greg Brown wrote: > I won't attempt to defend the collection literal proposal in particular, >> but I will point out that different parts of a program can stress different >> parts of your programming language. >> > > I agree that it is ideal to keep language sprawl on any given project to a > minimum. However, some languages are simply better suited to certain tasks > than others. Why not take advantage of it? Isn't that one of the reasons for > adding multi-language support to the JVM? No, language interoperability isn't a major goal of the JVM work. Rather, it attempts to make the JVM a better platform for single-language programming in languages other than Java. Don't expect easy interoperability between Java and other JVM languages. From gkbrown at mac.com Mon Jul 20 14:21:25 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 17:21:25 -0400 Subject: For further consideration, round 2 In-Reply-To: <3E5800CD-3807-4F05-AB42-5F83BB5841FE@zwitserloot.com> References: <3E5800CD-3807-4F05-AB42-5F83BB5841FE@zwitserloot.com> Message-ID: > If "It's not in java.lang" is a valid argument, then we should get > rid of the magic that makes java.io.Serializable work, as well as > the foreach loops, which use java.lang.Iterable, which refers to > java.util.Iterator, which is just not allowed in a java language > feature, apparently. IMO, Iterator belongs in java.lang. But it lives in java.util because it predates Iterable and for..each. And I'm not a big fan of "magic" in any capacity - Serializable is no exception. I don't like Serializable's special status. I don't particularly like String's special ability to use the "+" operator, either, but that's another story. > OR, we stop worrying about package names and treat proposals based > on their merits, instead of pointing out irrelevant distractions Even if we take that argument off the table, there's still the question of the type ambiguity and the viability of the use case, both of which question the proposal's overall merit. >> Map map = HashMap.unmodifiableMap(new >> Map.Pair("foo", 123), >> new Map.Pair("bar", 456)); > > Just look at it. And then look at this: > > Map map = {"foo": 123, "bar": 456}; > > Now choose which one you'd rather look at, let alone type. Sure, it's more readable. But it doesn't matter what you or I think is "prettier". It's a question of design. If such syntax can be achieved along with a good design, then I'm all for it. Otherwise, not so much. >> A language extension for pairs might make sense > > ... but list and map literals don't. Okay. Why? As I said, I think language-related classes belong in java.lang. So, if Pair is added to java.lang, there's a stronger argument for extending the syntax of the language to use it. > How would pairs type? A new 'java.util.Pair' type, or should it be > in java.lang, which means any existing class named Pair (and, boy, > are there many of those!) are now in a namespace conflict, causing > fun times for everyone that imports their own Pair class via a star > import? Fair enough. But that doesn't make the design wrong - it's just a practical challenge. >> But again, is there really a strong enough use case for collection >> literals in Java to justify any kind of language change? > > > Yes, there is. Do a code check on how many collection literals you > make versus how often you do a list member lookup by index. In my > code I'm looking at roughly a 50:1 ratio. Again, fair enough. I don't have such a strong use case, but perhaps others do. From gkbrown at mac.com Mon Jul 20 14:35:31 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 17:35:31 -0400 Subject: For further consideration, round 2 In-Reply-To: <15e8b9d20907201357r2d756a04i7b08fb43054c9587@mail.gmail.com> References: <15e8b9d20907201318p3f23cf1do71507c391eb8e9eb@mail.gmail.com> <39468512-D623-466C-A10B-83FF762B6EA9@mac.com> <15e8b9d20907201357r2d756a04i7b08fb43054c9587@mail.gmail.com> Message-ID: > No, language interoperability isn't a major goal of the JVM work. > Rather, it attempts to make the JVM a better platform for single- > language programming in languages other than Java. That's disappointing, if true. I like Java. I think it's great that the JVM supports other languages as well, but I plan to continue to write code in Java and use script occasionally when it's more efficient/intuitive (again, using the right tool for the job). > Don't expect easy interoperability between Java and other JVM > languages. To me, that is completely counterintuitive. I *absolutely* expect interoperability, and, from my experiences so far with Rhino, Groovy, and Scala, it is quite well supported. This is probably the wrong thread for any further discussion on this topic, though. From gkbrown at mac.com Mon Jul 20 14:39:59 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 17:39:59 -0400 Subject: Indexing access syntax for Lists and Maps In-Reply-To: References: Message-ID: <10AF6167-5D5E-4D61-B75F-00B2EA106390@mac.com> I'd like to separate the previous discussion into two threads, so the conversation regarding the merits of collection literals doesn't completely overshadow the other topic: > 1) Indexing access syntax for Lists and Maps > > It would be nice to see this feature extended to any class, not just > List and Map. Groovy supports this by mapping the index operator to > getAt() and putAt() - a similar approach (possibly one that maps to > get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and > would still work for List and Map. How viable might this be? From gkbrown at mac.com Mon Jul 20 16:13:45 2009 From: gkbrown at mac.com (Greg Brown) Date: Mon, 20 Jul 2009 19:13:45 -0400 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <10AF6167-5D5E-4D61-B75F-00B2EA106390@mac.com> References: <10AF6167-5D5E-4D61-B75F-00B2EA106390@mac.com> Message-ID: <70B8E119-2E7A-480F-BC46-D4A4DC9A92D3@mac.com> I've just looked back through some recent threads to see what has already been discussed. It seems like some consideration has been given to both approaches (a hard association between the [] operator and List/Map as well as some form of operator overloading). Would someone be willing to briefly summarize what is currently being proposed for indexer access? Thanks, Greg On Jul 20, 2009, at 5:39 PM, Greg Brown wrote: > I'd like to separate the previous discussion into two threads, so > the conversation regarding the merits of collection literals doesn't > completely overshadow the other topic: > >> 1) Indexing access syntax for Lists and Maps >> >> It would be nice to see this feature extended to any class, not just >> List and Map. Groovy supports this by mapping the index operator to >> getAt() and putAt() - a similar approach (possibly one that maps to >> get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and >> would still work for List and Map. > > > How viable might this be? > > From reinier at zwitserloot.com Mon Jul 20 18:03:56 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 21 Jul 2009 03:03:56 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <10AF6167-5D5E-4D61-B75F-00B2EA106390@mac.com> References: <10AF6167-5D5E-4D61-B75F-00B2EA106390@mac.com> Message-ID: <5F00E71D-9C49-4AF9-8FC9-610ED0CD8D4A@zwitserloot.com> Greg, reread some older threads. We've held an extremely extensive back-and-forth about implementing map/list index operators. A summary of the findings: 1. Whatever we come up with, it has to work with java.util.Map and java.util.List, otherwise, why bother? Map and List are both interfaces, so they cannot gain any new methods. Therefore, either (A) we 'hardcode' support in for those data types, or (B) we come up with an interface that mirrors a strict subset of the methods in those types. 2. Mirroring List's "T get(int)" is just fine, but "boolean set(int, T)" is problematic because of that 'boolean' return value. What should this: Object x = someArrayList[0] = "Hello"; System.out.println(x); print? People will expect 'Hello'. But if we just 'desugar' "list[idx] = foo" to "list.set(idx, foo)", then this will print "true", which is an instant java puzzler. Turning the return type to 'void' solves the problem, but won't be compatible with java.util.List, as "boolean set(int, T)" is just not compatible with "void set(int, T"). There are two fixes for this. The first is complex and has ramifications for the JVM: (A) add to the JLS that you can override a method that returns void, and change the void return type to something else (just like you can pick a more specific subtype if you want), but that's not enough, because you also need to add: (B) *UNLIKE* how specific subtype is implemented (a wrapper method at compile time), because there are existing Map implementations out there in class form, the class loader/ JVM needs to create and inject these wrapper methods on-the-fly, as the classes are loaded. The second fix is simpler but feels hackish: Declare java.util.List and java.util.Map 'magic', and while they DONT extend SetByKey/SetByIndex, they DO work with the map[foo] = val / list[idx] = val syntax. 3. Same situation (but worse) with Map: "V get(K)" is fine, but "V set(K, V)" is problematic, as it returns the OLD value associated with the key (usually null, in other words). So: System.out.println(map[key] = "Hello"); will print 'null', not 'Hello'. Puzzler. Bad. 4. Technically, the result of the "a = b" expression in the JLS is defined as not just "b", but "b, converted to fit into a". So: long foo; Object x = foo = 1; System.out.println(x.getClass()); will print "java.lang.Long" and not "java.lang.Integer" as you might expect. Trying to port this nuance to map/list is so complicated that no one to date has come up with a strategy that isn't going to confuse half of the java programmers out there. Nevertheless, my continued insistence that the only way forward is decide on making the map/list assignment sugar have the void type, and working out a way to implement this nicely, has been made with majority opposition. 5. Even though I consider the value of this proposal very low (who indexes into lists? You .add(), and you iterate), Joe Darcy continues to mention this proposal in coin posts, so apparently it isn't dead yet. --Reinier Zwitserloot On 2009/20/07, at 23:39, Greg Brown wrote: > I'd like to separate the previous discussion into two threads, so the > conversation regarding the merits of collection literals doesn't > completely overshadow the other topic: > >> 1) Indexing access syntax for Lists and Maps >> >> It would be nice to see this feature extended to any class, not just >> List and Map. Groovy supports this by mapping the index operator to >> getAt() and putAt() - a similar approach (possibly one that maps to >> get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and >> would still work for List and Map. > > > How viable might this be? > > > From Ulf.Zibis at gmx.de Tue Jul 21 00:56:05 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 21 Jul 2009 09:56:05 +0200 Subject: For further consideration, round 2 In-Reply-To: References: Message-ID: <4A657495.6010103@gmx.de> Am 20.07.2009 22:09, Greg Brown schrieb: > Map map = HashMap.unmodifiableMap(new > Map.Pair("foo", 123), > new Map.Pair("bar", 456)); > > A language extension for pairs might make sense, if Pair was defined > in java.lang Hm, why you are thinking about a new type, we just have java.util.MapEntry? And we have public constructors from AbstractMap.SimpleEntry and AbstractMap.SimpleImmutableEntry. Language extension could map [ final {"foo":123}] to [ new AbstractMap.SimpleImmutableEntry("foo", 123) ] or, we even don't need the braces, so have: [ "foo":123] and [ final "foo":123] The only thing, I dislike, is the 'Abstract' part of the naming. We can't extend Map for add(MapEntry), but we can extend HashMap etc., (or have new ExtendedMap interface) HashMap hm; hm["foo"] = 123; // should work hm["foo"] = final 123; // should put new AbstractMap.SimpleImmutableEntry("foo", 123) Map m; m["foo"] = 123; // compile error Although I can live without indexing access syntax (hm.put("foo":123) is quite readable and smart), I much like the pair literal (better named 'map entry literal', as semantic of 1st and 2nd element aren't equal). It enables the opportunity for collection/array literals: {"foo":123, "bar":456, ...} BTW: I would like to see: foo({"Hello", "World"}); for void foo(T.. elements); and String[] sa; sa = {"Hello", "World"}; -Ulf From Joe.Darcy at Sun.COM Tue Jul 21 13:02:33 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 21 Jul 2009 13:02:33 -0700 Subject: Combined grammar changes for binary literals and underscores in literals In-Reply-To: <4A5E4898.5000708@sun.com> References: <4A5E4898.5000708@sun.com> Message-ID: <4A661ED9.4060004@sun.com> Hello. It has been pointed out to me off-list that the grammar as written below would disallow two-digit numbers, which is not desired. This problem is corrected by changing the productions like Digit DigitsAndUnderscores Digit to be Digit DigitsAndUnderscores_opt Digit -Joe On 07/15/09 02:22 PM, Joseph D. Darcy wrote: > Hello. > > Getting around to some grammatical hacking, below is a grammar I think > properly captures the desired changes for combining the binary > literals and underscores in literals proposals. This grammar does > *not* include support for unsigned literals or autosizing literals. > > The basic approach is to redefine the FooDigits productions to be a > non-empty sequence of Foo digits and underscores starting and ending > with a Foo digit rather than just a non-empty sequence Foo digits. > Each FooDigits nonterminal has two rules, one for a single digit and > one for two or more digits. The rules for two or more digits force a > true digit, rather than an underscore, as the first and last character. > > Changing the FooDigits definitions allows underscores in both integer > and floating-point literals. In more detail: > > * Replace the productions Digits, HexDigits, OctalDigits, and in > JLSv3 3.10.1 as shown below > * Add productions for BinaryDigits > * Add rules for FooDigitsAndUnderscores and FooDigitOrUnderscore > * Add productions to DecimalNumeral and OctalNumeral: > * Add a rule for Underscores > > IntegerLiteral: > DecimalIntegerLiteral > HexIntegerLiteral > OctalIntegerLiteral > BinaryIntegerLiteral // New > > BinaryIntegerLiteral: > BinaryNumeral IntegerTypeSuffix_opt > > BinaryNumeral: > 0 b BinaryDigits > 0 B BinaryDigits > > > DecimalNumeral > 0 > NonZeroDigit Digits_opt > NonZeroDigit Underscores Digits // New > > Underscores > _ > Underscores _ > > Digits: > Digit > Digit DigitsAndUnderscores Digit > > DigitsAndUnderscores: > DigitOrUnderscore > DigitsAndUnderscores DigitOrUnderscore > > DigitOrUnderscore > Digit > _ > > > HexDigits: > HexDigit > HexDigit HexDigitsAndUnderscores HexDigit > > HexDigitsAndUnderscores: > HexDigitOrUnderscore > HexDigitsAndUnderscores HexDigitOrUnderscore > > HexDigitOrUnderscore > HexDigit > _ > > OctalNumeral: > 0 OctalDigits > 0 Underscores OctalDigits // New > > OctalDigits: > OctalDigit > OctalDigit OctalDigitsAndUnderscores OctalDigit > > OctalDigitsAndUnderscores: > OctalDigitOrUnderscore > OctalDigitsAndUnderscores OctalDigitOrUnderscore > > OctalDigitOrUnderscore > OctalDigit > _ > > BinaryDigits: > BinaryDigit > BinaryDigit BinaryDigitsAndUnderscores BinaryDigit > > BinaryDigitsAndUnderscores: > BinaryDigitOrUnderscore > BinaryDigitsAndUnderscores BinaryDigitOrUnderscore > > BinaryDigitOrUnderscore > BinaryDigit > _ > > BinaryDigit: one of > 0 1 > > -Joe From Eamonn.McManus at Sun.COM Wed Jul 22 02:40:21 2009 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Wed, 22 Jul 2009 11:40:21 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: References: Message-ID: <4A66DE85.4050100@sun.com> Reinier Zwitserloot writes: > 2. Mirroring List's "T get(int)" is just fine, but "boolean set(int, T)" > is problematic because of that 'boolean' return value. What should this: > > Object x = someArrayList[0] = "Hello"; > System.out.println(x); > > print? People will expect 'Hello'. But if we just 'desugar' "list[idx] = > foo" to "list.set(idx, foo)", then this will print "true", which is an > instant java puzzler. In addition to the options you mention later in your message, it seems to me that a reasonable option would be to say that the value of someArrayList[0] = "Hello" is the value assigned. The fact that list.set returns something else doesn't have to be relevant. The JLS currently says that "the result of the assignment expression is the value of the variable after assignment has occurred", and it is obvious how this should be extended for lists and maps. ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/emcmanus/ From reinier at zwitserloot.com Wed Jul 22 05:01:36 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 22 Jul 2009 14:01:36 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <4A66DE85.4050100@sun.com> References: <4A66DE85.4050100@sun.com> Message-ID: <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> Your suggestion has been discussed quite a bit, IIRC. It's not a clear winner by any means. To wit: 1. For people who consider x[y] = z as syntax sugar for x.set(y, z), this is going to catch them out. In particular, they may just run a blanket search/replace for the "list.set(idx, val)" pattern and replace it with list[idx] = val, and thus produce code which is buggy, but the bug is not at all obvious. 2. You now have an interface powering a language feature where you HAVE TO return something, but whatever you return is ALWAYS ignored. That's rather silly, not to mention actively confusing in that it strongly suggests the value of the expression is what you return from this method. It may have to be acceptable collateral damage to be compatible with java.util.Map/List, but making this deliberation seems impossible given the limited timespan between now and java7's release. 3. You still have to deal with the notion that the value of any assignment expression is currently defined as a rough analogue to 'the actual value of the thing you're assigning to, post-assignment'. The idea behind this, no doubt, is that you can use 'tunnel vision' and consider only "A = B" when reading "A = B = C = D = E = F" if you are so inclined. This indeed holds for all current assignments, but for lists and maps, this will not hold unless a subsequent get call is generated. Who knows - maybe that List takes only integers and will increment each integer by 1 prior to storing it for some reason. I will make one last plea for sanity here and reiterate my belief that the only right answer (if there is one) is that a[b] = z MUST NOT be an expression, but a statement. There are at least 5 reasonable but mutually exclusive interpretations of what it ought to be, as covered in this review of the issues: 1) the old object at the given index / the old value associated with the given key, as per Map.put and List.set. 2) The RHS, unmodified (wrong on all accounts, but nevertheless, if you go out on the street and interview Joe Q. Random Java Programmer about the value of "a = x", this one will win hands down, and is therefore de facto a reasonable answer, unless we want to consider the majority of java programmers as unreasonable, which seems like a rather ill informed plan). 3) The RHS, but converted so that it fits (in this case, essentially: box first if the RHS is a primitive). 4) a = b[c] = d; is equal to b[c] = d; a = b[c]; (the tunnel vision argument: A = B = C is, as far as A is concerned, equal to A = B). 5) Assignments aren't expressions, so, no value. (wrong, but a popular style rule). The problem with 4 out of those 5 is: If you get the answer wrong, your code will do subtly different things that's going to take you a long time to debug. Therefore, #5 wins, because when you pick the wrong answer, the resulting error in your code is: A) generated at compile time (in IDEs, as you write it, instant red- line). For all others, it would be a run-time problem. B) generated in the right place (at the place where you write the assignment-as-expression, and not in some other place, which is where you're going to get your surprise in the other 4 options) C) generated with a concise and obvious error message: "List/Map index/key assignment may not be used an expression." For all others, you won't even get an exception, you'll just end up with a value you weren't at all suspecting. Hence, I rate the man-hour cost of getting the answer wrong as over an hour for #1-#4, but more like 10 seconds for #5. The fact that its a popular style rule (e.g. people who will even try to use an assignment as an expression is low) is just gravy. #5 is therefore the only right answer, Unless consistency is of tantamount importance, in which case there is no right answer, and this proposal must not go forward. --Reinier Zwitserloot On 2009/22/07, at 11:40, Eamonn McManus wrote: > Reinier Zwitserloot writes: >> 2. Mirroring List's "T get(int)" is just fine, but "boolean >> set(int, T)" >> is problematic because of that 'boolean' return value. What should >> this: >> >> Object x = someArrayList[0] = "Hello"; >> System.out.println(x); >> >> print? People will expect 'Hello'. But if we just 'desugar' >> "list[idx] = >> foo" to "list.set(idx, foo)", then this will print "true", which is >> an >> instant java puzzler. > > In addition to the options you mention later in your message, it > seems to me > that a reasonable option would be to say that the value of > > someArrayList[0] = "Hello" > > is the value assigned. The fact that list.set returns something > else doesn't > have to be relevant. The JLS currently says that "the result of the > assignment > expression is the value of the variable after assignment has > occurred", and it > is obvious how this should be extended for lists and maps. > > ?amonn McManus ? JMX Spec Lead ? http://weblogs.java.net/blog/ > emcmanus/ > > From jjb at google.com Wed Jul 22 07:49:20 2009 From: jjb at google.com (Joshua Bloch) Date: Wed, 22 Jul 2009 07:49:20 -0700 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> References: <4A66DE85.4050100@sun.com> <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> Message-ID: <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> Reinier, On Wed, Jul 22, 2009 at 5:01 AM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > Your suggestion has been discussed quite a bit, IIRC. It's not a clear > winner by any means. For what it's worth, I believe it *is* a clear winner. The arguments against it confuse implementation with interface. No one is going to worry about how its implemented. People will want the same sort of polymorphism offered by the for-each statement. If you have: a[i] = a[j] = k; the behavior must not differ depending on whether a is an array or a list. Josh P.S. I am so sorry to bring this dead horse back to life. From Ulf.Zibis at gmx.de Wed Jul 22 09:57:54 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 22 Jul 2009 18:57:54 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> References: <4A66DE85.4050100@sun.com> <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> Message-ID: <4A674512.6060305@gmx.de> Am 22.07.2009 16:49, Joshua Bloch schrieb: > > For what it's worth, I believe it *is* a clear winner. The arguments against > it confuse implementation with interface. No one is going to worry about > how its implemented. People will want the same sort of polymorphism offered > by the for-each statement. If you have: > > a[i] = a[j] = k; > > the behavior must not differ depending on whether a is an array or a list. > +1; very simple and clear, all mapping issues against underlying just existing map/list/etc/API should be solved by compiler. Just adding to recent discussion about the print question: We could distinguish between: print(map["foo"] = 123); // prints 123 print((map["foo"]) = 123); // prints 123 print(old = (map["foo"] = 123)); // prints old - Ulf From Ulf.Zibis at gmx.de Wed Jul 22 10:54:30 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 22 Jul 2009 19:54:30 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> References: <4A66DE85.4050100@sun.com> <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> Message-ID: <4A675256.8080205@gmx.de> Am 22.07.2009 16:49, Joshua Bloch schrieb: > For what it's worth, I believe it *is* a clear winner. The arguments against > it confuse implementation with interface. No one is going to worry about > how its implemented. People will want the same sort of polymorphism offered > by the for-each statement. If you have: > > a[i] = a[j] = k; > Maybe (a[i] = a[j]) = k; could result in get old value for LHS + update by k. (But this semantics would tend to be misunderstood). -Ulf From reinier at zwitserloot.com Wed Jul 22 13:36:55 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 22 Jul 2009 22:36:55 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> References: <4A66DE85.4050100@sun.com> <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> Message-ID: <497E58A3-B2FE-4EE2-82D6-971393C353B0@zwitserloot.com> On 2009/22/07, at 16:49, Joshua Bloch wrote: > The arguments against it confuse implementation with interface. I don't understand what you mean. How is the argument "This is going to cause subtle, hard to find bugs for the majority of the java programming public" confusing implementation with interface? NB: Ulf - yes, by all means, add even more complicated rules to this thing. From Ulf.Zibis at gmx.de Wed Jul 22 13:51:04 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 22 Jul 2009 22:51:04 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <497E58A3-B2FE-4EE2-82D6-971393C353B0@zwitserloot.com> References: <4A66DE85.4050100@sun.com> <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> <497E58A3-B2FE-4EE2-82D6-971393C353B0@zwitserloot.com> Message-ID: <4A677BB8.1010702@gmx.de> > NB: Ulf - yes, by all means, add even more complicated rules to this > thing. > > Sorry, I'm afraid my creativity stack is now empty. :-[ Remember: I said: (But this semantics would tend to be misunderstood). From abies at adres.pl Wed Jul 22 14:12:20 2009 From: abies at adres.pl (Artur Biesiadowski) Date: Wed, 22 Jul 2009 23:12:20 +0200 Subject: Indexing access syntax for Lists and Maps In-Reply-To: <497E58A3-B2FE-4EE2-82D6-971393C353B0@zwitserloot.com> References: <4A66DE85.4050100@sun.com> <8758F2E4-2ACF-445C-BB3A-A4D3E4850173@zwitserloot.com> <17b2302a0907220749h267bca5dy9f1031876bf2296d@mail.gmail.com> <497E58A3-B2FE-4EE2-82D6-971393C353B0@zwitserloot.com> Message-ID: <4A6780B4.9090906@adres.pl> Reinier Zwitserloot wrote: > I don't understand what you mean. How is the argument "This is going > to cause subtle, hard to find bugs for the majority of the java > programming public" confusing implementation with interface? > This was probably counterargument for having m[x] = y returning old value of m[x]. Only bugs "m[x]=y returning y converted to proper type" might cause is if somebody blindly replaces something(m.put(x,y)) with something(m[x]=y). To be honest, second construct is a red alert for me even now (with current array assignment). I do not think that case of going through old code are replacing it en masse with new [] accessors is something we should worry about - people would not do it by hand and if tools are there, they can be smart enough to avoid it. What we should worry about is new code written - so it contains least surprises. For me, this means that m[x]=y should behave same way for maps/list as for arrays. I expect a lot more common use to start with array and then change it to use ArrayList. With new accessors, you just have to modify arguments/variables - rest of the code stays and behaves the same. About choices 2 and 3 in your case. It is true that most java programmers would answer RHS unmodified, but they would also probably have hard time to understand difference between 2 and 3 at all. So, for our 'Random Java Programmer', choices 2 and 3 are the same - which is a benefit, because 2 is following 'intuition', while 3 is following JLS for arrays. Anyway, if this solution is not chosen, I think that not returning anything is second best. I would certainly hate returning old value inside container, or having 'tunnel' solution, as they are completely against current behavior for arrays. Regards, Artur Biesiadowski From amalter at illegalcheese.com Mon Jul 20 18:15:58 2009 From: amalter at illegalcheese.com (Adam Malter) Date: Mon, 20 Jul 2009 21:15:58 -0400 Subject: General community and Process Questions (blog comment followups) Message-ID: <613a548a0907201815t7fa1ef3fj61f4c077dbbb3ada@mail.gmail.com> Hi all, I'm hoping to productively bring your attention to an off-list discussion. Recently the jdk7 announce blog "The Planetarium" posted a short teaser on the state of the upcoming jdk7 language changes ( http://blogs.sun.com/theplanetarium/entry/summarizing_java_language_changes_for). As often seems to happen (and I'll admit to being part of), the comments turned into a negative compliant-fest on current proposal set and process for coin. So, while guilty of the sin, I've also felt it a bit unfair. I've been following Joe Darcy's blog and lurking here on the list from nearly the inception. It is obvious to me that everyone involved is attempting to be as open and receptive as possible. Certainly creating a coin proposal and the mostly constructive criticism they receive here is night and day compared to the opaque and complex (from the outside) JSR process. However, when initially responding to the blog post, I also felt a bit of frustration and I believe I've boiled it down into two core issues that may turn out to be misunderstandings. So here goes.. a) The two proposals initially mentioned by the first blog commenter, regex or non-backslash escaping and multi-line string declarations, seem to meet the project coin mission perfectly. They have a large positive usability impact and a large group of casual advocates, additionally, from those unfamiliar with the jdk internals, they seem like "small" changes already present in most other modern languages. However, (from the outside) it appears that those proposals have been dropped and it's unclear why. I believe that this has lead to some people into dismissing the entire process as capricious and opaque. Would it be possible to get an insiders explanation on why these proposals are off the table? Is it just that no one wrote a formal proposal? (I'm guessing not, and if I had to take a stab I'd say that there are some lurking nasty grammar parser issues around change string constant declarations. However, if someone could clarify, even if it's just something like "changing javac's parser to accommodate this would be a nightmare", I think people would understand.) This leads to b) What is the process for finalizing the changes that go into coin and then get folded into the jdk. I understand that people who participate here have some influence, but who has final say? Does the whole thing get wrapped up in a JSR and get voted? Is it just a judgement call of the internal Sun architects? Understanding the process would really help it feel more 'open' and I think get people psyched about contributing. If this has all been answered before, I apologize, just point me in the right direction. Anyway, I'd also like to thank everyone working on the current set of proposals. There is a lot of cool stuff in there that will make the language and platform better. Thanks for your time, -Adam Malter @ tradecard . com From Joe.Darcy at Sun.COM Fri Jul 24 22:21:33 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 24 Jul 2009 22:21:33 -0700 Subject: General community and Process Questions (blog comment followups) In-Reply-To: <613a548a0907201815t7fa1ef3fj61f4c077dbbb3ada@mail.gmail.com> References: <613a548a0907201815t7fa1ef3fj61f4c077dbbb3ada@mail.gmail.com> Message-ID: <4A6A965D.6010801@sun.com> Hello. > Hi all, > > I'm hoping to productively bring your attention to an off-list > discussion. Recently the jdk7 announce blog "The Planetarium" posted > a short teaser on the state of the upcoming jdk7 language changes > (http://blogs.sun.com/theplanetarium/entry/summarizing_java_language_changes_for). > As often seems to happen (and I'll admit to being part of), the > comments turned into a negative compliant-fest on current proposal > set and process for coin. Yes, I had seen the Planetarium post and responding to the concerns you raise below on this list is the right forum. [snip] > So here goes.. > > a) The two proposals initially mentioned by the first blog commenter, > regex or non-backslash escaping and multi-line string declarations, > seem to meet the project coin mission perfectly. They have a large > positive usability impact and a large group of casual advocates, > additionally, from those unfamiliar with the jdk internals, they seem > like "small" changes already present in most other modern languages. > > > However, (from the outside) it appears that those proposals have been > dropped and it's unclear why. I believe that this has lead to some > people into dismissing the entire process as capricious and opaque. > Would it be possible to get an insiders explanation on why these > proposals are off the table? Is it just that no one wrote a formal > proposal? > [snip] As a general comment, as I've stated before Project Coin's call for proposals phase [1], the overriding responsibility is for the proposer (or other advocate for the change) to positively demonstrate why a change should get *in*, the responsibility is not to prove that a change should stay out. At a minimum that requires a proposal to stay within the size bounds in all of the specification, implementation, and testing dimensions. [2] Additionally, even if a Coin Proposal is in scope size-wise, the proposal must also be a good way to evolve Java. Detailing why a proposal fails in one or more of these ways is very time consuming; indeed, for some of the proposals that were sent in, writing a rebuttal could take longer than the time spent on the proposal ;-) Given the nearly 70 proposals that were sent it, it is not practical to provide a detailed analysis of all or even most proposals since it could easily consume several solid months of engineering time, engineering time that would be more productively directed at implementing good proposals. Even if the analysis were done, at the end of those months, I'm confident not all the advocates would be convinced of the flaws in their proposals and there would be many more proposals eager to be evaluated if that evaluation continued to be offered. Many proposals sent into Coin were not well written and lacked prototypes. While the string proposal in question was sent in early, went through several helpful iterations of refinement on the list, and laudably included a prototype implementation, in the end I thought the proposal provided limited benefits over the alternatives for the complexity it introduced. > This leads to > > b) What is the process for finalizing the changes that go into coin > and then get folded into the jdk. I understand that people who > participate here have some influence, but who has final say? Does the > whole thing get wrapped up in a JSR and get voted? Is it just a > judgement call of the internal Sun architects? Understanding the > process would really help it feel more 'open' and I think get people > psyched about contributing. At the moment, informed by the discussions on the mailing list and in consultation with people inside and outside of Sun, I have the final say to determine the list of small language changes for JDK 7. As has been previously stated, our intention is to file a JSR for the language changes after the feature list has been determined. Having been a spec lead previously, JSRs are not democracies either, although consensus driven decision making is preferred and encouraged. There are numerous reasons for this decision making arrangement, some of which I will discuss below. The blog entries I wrote last year and before [3] [4] about experiences evolving the Java language were intended to allow interested people to participate much more fully in the language evolution process by providing context about what work is needed and what some of the concerns are. The Coin list has been a good start to building the skill level for broader participation. However, any feature added to the Java programming language must be supported *FOREVER* and only Sun has been willing to do that. That is why we reserve the right to have the final word over language decisions. In the context of Project Coin, just sending in a rough idea or request for a language change essentially has no value since there are already many, many more ideas for reasonable languages changes than can be accommodated in JDK 7 or any subsequent release. The hard part, and the most valuable part, is the work analyzing the impact and benefit of a change, which ideally includes a prototype. Project Coin invited community participation in that work. "Design by committee" is often derided as an inappropriate way to manage technical projects. Simple polling about technical issues is design by committee where the committee can be arbitrarily large and any pretense of expertise in the area is removed. Therefore, polling would be a poor way to drive specific technical decisions about the Java Programming Language. One of the benefits of working in a technical field is that technical problems often have right answers, regardless of how many people agree or disagree with them. This is not intended to be a slight against Java programmers who contributed suggestions informed by their daily experiences with the language to the Coin alias, to Sun's bug database, or elsewhere. Rather, it is a recognition that, just as being a player and being a coach are district roles requiring distinct skills, using the language and evolving it and district tasks with related but separate skills sets. Polling can provide a good indication about what pain points people are experiencing; that is an important input, but only one kind of input, to how the language should change. Most Java programmers do not need to be language experts. This is very much a feature and *not* a bug of the Java ecosystem. Not having to be a language expert means Java programmers have time to be experts about other things :-) One of Project Coin's goals is to build up a larger body of expertise outside of Sun that can analyze, quantify, measure, and evaluate developments in the Java language.. A good way to get influence is to do some work. I've been a bit disappointed in several aspects of the coin contributions. For example, back in May there was an open issue concerning the grammar changes needed for underscores in numbers [5]. No one sent in a message on this matter until I sent in a grammar in July [6]. Neither the coin list nor readers on my blog caught the embarrassing but small mistake I made in the grammar [7]. In terms of difficulty of language evolution, this grammar change is easy. Having taken an undergraduate class in compilers or automata theory is sufficient background to work on this, but no one else contributed a grammar for this despite presumed interest in the feature and the large number of coin subscribers. I am not aware of any independent assessment of the utility of sets of coin features together or other systematic analysis of the proposals. Collectively the Coin community to date has neither managed to get all the small details of proposals worked out nor provided an alternative larger view of the potential goals for the effort. Sun has been working on the Java language for many years, is in a position to get input and feedback from numerous parties (including Coin!), understands the need for thorough analysis and mature evaluation, and has provided ongoing support. Therefore ultimate decision making on Java language changes will stay with Sun. All the code needed to develop a language change is now available from OpenJDK. People are now able to "scratch their own itch" in experimenting with language changes and for those not wanting to work directly under the auspices of the OpenJDK umbrella project, there are alternatives (https://kijaro.dev.java.net/). I encourage those who want to see more language changes in Java to complain less and code (and propose and test and analyze) more; that is the best way to be convincing that a change should go into Java. As a counterpoint, I counsel against the too-common habit of showing up with no money and no technical expertise and expecting others to drop their own priorities to undertake a massive engineering project on another's behalf. [8] Regards, -Joe [1] "Criteria for desirable small language changes," http://blogs.sun.com/darcy/entry/criteria_for_desirable_small_language [2] "Guidance on measuring the size of a language change" http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size [3] "Project Coin: Small Language Change Proposal Form Available," http://blogs.sun.com/darcy/entry/project_coin [4] "So you want to change the Java Programming Language...", http://blogs.sun.com/darcy/entry/so_you_want_to_change [5] http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001882.html [6] http://mail.openjdk.java.net/pipermail/coin-dev/2009-July/002080.html [7] http://mail.openjdk.java.net/pipermail/coin-dev/2009-July/002110.html [8] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000666.html http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000691.html http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000706.html From rssh at gradsoft.com.ua Sat Jul 25 01:29:53 2009 From: rssh at gradsoft.com.ua (Ruslan Shevchenko) Date: Sat, 25 Jul 2009 11:29:53 +0300 (EEST) Subject: General community and Process Questions (blog comment followups) In-Reply-To: <4A6A965D.6010801@sun.com> References: <613a548a0907201815t7fa1ef3fj61f4c077dbbb3ada@mail.gmail.com> <4A6A965D.6010801@sun.com> Message-ID: > Hello. > >> Hi all, >> > > Many proposals sent into Coin were not well written and lacked > prototypes. While the string proposal in question was sent in early, > went through several helpful iterations of refinement on the list, and > laudably included a prototype implementation, in the end I thought the > proposal provided limited benefits over the alternatives for the > complexity it introduced. > May be part of fault with multiline string proposal liew with me: I wrote first version of multiline string proposal, without knowing about analogical proposal of Steve Colebourne (which was relative well-knonw in Sun, as I guess now); this fact potentially can provoke some social issues. (interesting, than later I found 6 different proposals, implementations or warkarrounds on this subject, laying arround in blogs and mail-lists) >From other side, I does not think that pre-final version of proposal was badly-defined ( http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html ) Especially, if we compare this with some of proposals, which were accepted, like indexed access to collections (http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001108.html) Knowing, that coin proposals are not final decisions of all details, but only entries for work of JSR expert group, I think that quality of proposal (after some not-so-big barrier) was not a main factor of choice. Extra complexity can be deleted on expert group stage. Finally what to do next: I summarize all about multiline strings in Java (http://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw&hl=ru ) [with open issue about 'IDE-friendly' marker] and if will exists possibility to submit JSR only with a multiline strings - I propose interesting parties coordinate (here or in any other public place) and submit one, using this document as starting point. [Difficult part is find somebody in Sun, familiar with JSR procedures to participate]. >> This leads to >> >> b) What is the process for finalizing the changes that go into coin >> and then get folded into the jdk. I understand that people who >> participate here have some influence, but who has final say? Does the >> whole thing get wrapped up in a JSR and get voted? Is it just a >> judgement call of the internal Sun architects? Understanding the >> process would really help it feel more 'open' and I think get people >> psyched about contributing. > ................ > > coin contributions. For example, back in May there was an open issue > concerning the grammar changes needed for underscores in numbers [5]. > No one sent in a message on this matter until I sent in a grammar in > July [6]. Neither the coin list nor readers on my blog caught the > embarrassing but small mistake I made in the grammar [7]. In terms of > difficulty of language evolution, this grammar change is easy. Having > taken an undergraduate class in compilers or automata theory is > sufficient background to work on this, but no one else contributed a > grammar for this despite presumed interest in the feature and the large > number of coin subscribers. > May be this shown, that interest to number literals is relative small ? From amalter at illegalcheese.com Sat Jul 25 09:35:17 2009 From: amalter at illegalcheese.com (Adam Malter) Date: Sat, 25 Jul 2009 12:35:17 -0400 Subject: General community and Process Questions (blog comment followups) In-Reply-To: References: <613a548a0907201815t7fa1ef3fj61f4c077dbbb3ada@mail.gmail.com> <4A6A965D.6010801@sun.com> Message-ID: <613a548a0907250935v4490269h51d15071ada2ecf8@mail.gmail.com> Joe writes: > > Most Java programmers do not need to be language experts. ?This is very much a feature and *not* a bug of the Java ecosystem. ?Not having to be a language expert means Java programmers have time to be experts about other things :-) > > One of Project Coin's goals is to build up a larger body of expertise outside of Sun that can analyze, quantify, measure, and evaluate developments in the Java language.. ?A good way to get influence is to do some work. ?I've been a bit disappointed in several aspects of the coin contributions. ?For example, back in May there was an open issue concerning the grammar changes needed for underscores in numbers [5]. ?No one sent in a message on this matter until I sent in a grammar in July [6]. ? Neither the coin list nor readers on my blog caught the embarrassing but small mistake I made in the grammar [7]. ?In terms of difficulty of language evolution, this grammar change is easy. ?Having taken an undergraduate class in compilers or automata theory is sufficient background to work on this, but no one else contributed a grammar for this despite presumed interest in the feature and the large number of coin subscribers. > > Collectively the Coin community to date has neither managed to get all the small details of proposals worked out nor provided an alternative larger view of the potential goals for the effort. ?Sun has been working on the Java language for many years, is in a position to get input and feedback from numerous parties (including Coin!), understands the need for thorough analysis and mature evaluation, and has provided ongoing support. ?Therefore ultimate decision making on Java language changes will stay with Sun. First of all, Joe, thank you for the thorough and?thoughtful?reply. I can fully understand your frustration with people who bring complaints, but not contributions. This is an unfortunate 'bug' of the village commons, and if we were to fix it, I believe we'd all be having dinner in?Stockholm very soon. :) To get more concrete here, part of out problem is that anyone outside of Sun or otherwise unfamiliar with the semi-formal proposal process, needs to 'go through the meat grinder' before their work will resemble the quality of one created by insiders. This is just an inevitable by product of externalizing an internal process. I would just ask that this be taken into account when judging the 'quality' of a proposal. Additionally, we all have our biases and individual ideas on how to best mutate the language for further growth. I will rapidly assent that most users of the language (especially users that work in a single problem domain) don't have the long term vision that language designers require. All of these things are very true, but we seem to be stuck in a more pragmatic ditch. To bring us down to earth a bit, project coin seems to be the best last hope for introducing useful language constructs into Java (well, for this decade at least). It seems to me that Joe has been charged with a monumentally difficult task, which is to fix the impedance mismatch between the subjective proposals and what would truly fulfill the mission of finding the loose change language constructs that would most benefit the current ecosystem and further the language growth. As in your analogy Joe, as 'coach', you cannot be influenced by your own nits and prejudges, but must do whats best for the 'team'. My personal opinion on this would be the introduction of the tripe-quote or @" (aka C#) enhanced string literal definition. I'm honestly unsure if this would be the 'best bang for the buck' feature change, because I work in only a few problem domains and because I have never been a language designer. It is also no fault but my own that it was not until recently that I understood the process that would lead to this language change. > The hard part, and the most valuable part, is the work analyzing the impact and benefit of a change, which ideally includes a prototype. Project Coin invited community participation in that work. So I guess my question becomes (to both Joe and Ruslan), is there anything that we can do at this late stage to influence the process? If we could put effort into producing a prototype parser now, would there still be enough time to consider it? (I've done an ANTLR SQL grammar, so, hopefully some of that transfers over) I don't want it to be too little, too late, and fully accept your counsel on showing up empty handed. (Too late I understand, but I'm willing to work with Ruslan, whoever, to come back with something working and worthwhile and to maybe overcome some your disappointment and actually have some true community contribution) It's also only now that I understand the greater mission of coin, which was to not only introduce small grammer changes, but also help 'teach' the community to stand on their own. Consider this part of the learning process. - adam malter @ tradecard . com From rssh at gradsoft.com.ua Mon Jul 27 07:29:12 2009 From: rssh at gradsoft.com.ua (Ruslan Shevchenko) Date: Mon, 27 Jul 2009 17:29:12 +0300 (EEST) Subject: General community and Process Questions (blog comment followups) In-Reply-To: <613a548a0907250935v4490269h51d15071ada2ecf8@mail.gmail.com> References: <613a548a0907201815t7fa1ef3fj61f4c077dbbb3ada@mail.gmail.com> <4A6A965D.6010801@sun.com> <613a548a0907250935v4490269h51d15071ada2ecf8@mail.gmail.com> Message-ID: > > So I guess my question becomes (to both Joe and Ruslan), is there > anything that we can do at this late stage to influence the process? > If we could put effort into producing a prototype parser now, would > there still be enough time to consider it? (I've done an ANTLR SQL > grammar, so, hopefully some of that transfers over) > Look's like you not read next lines in replies to you first letter: )While the string proposal in question was sent in early, ) went through several helpful iterations of refinement on the list, and ) laudably included a prototype implementation, in the end I thought the ) proposal provided limited benefits over the alternatives for the ) complexity it introduced. [Joe Darcy] ) I does not think that pre-final version of proposal was ) badly-defined ( ) http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html ) [I ]// and if you look to proposal, you will see link to implementation. I.e. we have this proposal well-defined and implemented; all technical work was done in March. This feature was not included to future considerations for some reasons (I hope Sun does not plan to drop Java in favor on PL/SQL, but who knowns:) If we want push this future into Java, better way will be not require from project owner to invert previous decisions, but to receive clear unswer on next question: What from two sentences: - (A) Multiline strings and row literals must not be on Java language for some reason, forever. - (B) Multiline strings and row literals are potentially usefull and can be added to Java, but unlikely this feature can be fully analyzed and implemented in project coin becouse of time and complexity limits. better reflect Sun (or Joe Darcy) point of view. on (A) - we must shut up and switch to (other-favorite-language) on (B): May be exists possibility add this future not to Java 7 (where we have strict schedule), but in Java 7.1 (still without schedule but I hope in this decade). For example, anybody can submit JSR, which will be accepted or rejected by PMO. In principle, If I receive answer (B) and consent from Joe to participate in feature development of this feature -- I can submit this JSR on next day after coin JSR will be submitted. [If somebody from Sun will submit one - this will be better] May be exists other ways (for example made coin-like projects regular will be a good idea). P.S. Also I does not want long philosophical discussion, but must say that language development is not techical task with one solution: if you believe this, than you must belive that exists one true ideal programming language. To say more: if technical problem have only one solution: it's trivial problem. From vapor1 at teleport.com Mon Jul 27 13:47:00 2009 From: vapor1 at teleport.com (Derek Foster) Date: Mon, 27 Jul 2009 13:47:00 -0700 (GMT-07:00) Subject: General community and Process Questions (blog comment followups) Message-ID: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> >> coin contributions. For example, back in May there was an open issue >> concerning the grammar changes needed for underscores in numbers [5]. >> No one sent in a message on this matter until I sent in a grammar in >> July [6]. Neither the coin list nor readers on my blog caught the >> embarrassing but small mistake I made in the grammar [7]. In terms of >> difficulty of language evolution, this grammar change is easy. Having >> taken an undergraduate class in compilers or automata theory is >> sufficient background to work on this, but no one else contributed a >> grammar for this despite presumed interest in the feature and the large >> number of coin subscribers. > > May be this shown, that interest to number literals is relative small ? I think that this more realistically indicates that everybody considers this someone else's problem to fix. (Presumably, mine, since I submitted the original proposal.) Unfortunately, I have been slammed lately by an upcoming product release at work as well as some issues in my personal life, and have had little time to do much else other than try to at least read the Project Coin list messages as they go by. I did put together an initial draft of a fix to the issues Joe raised, but I didn't have time to really run it through the wringer and analyze it for problems, so I didn't submit it to the list yet. When Joe submitted his fix, I was quite relieved that someone else had had the time to do a more complete job of it, and I was planning to go over it in detail, but I just haven't had time yet. This is unfortunately a risk of having work done by volunteers -- since they aren't getting paid for the work they do, the work is subject to being delayed due to work that people ARE paid to do. As a result, realistically, extra time needs to be allocated for volunteer-driven efforts, and/or some kind of structure needs to be put in place so that if one person has trouble keeping up, that others can shoulder the load in some sort of controlled fashion. Right now, it is basically expected that whoever originally submitted a proposal is responsible for shepherding it through every distinct phase of its development, from proposal, to design, to implementation, answering criticisms about it, revising it, prototyping it, etc. etc. This is a LOT of work for one person. (It also requires that a single person be skilled in every step of the process, which requires a lot of different skills to be present in one person. A rare mix, which is unfortunately a significant limiting factor on proposals.) Of course, people who are interested in the proposal but not responsible for it are willing to offer criticisms, but not necessarily help (since raising issues takes MUCH less time than fixing them, after all). I think that this is a weakness of the process that Coin is using, and one that should be addressed in a future effort of this sort. In any case, this is all I have time to write at the moment, since I am about to get in a car and take a much-needed vacation (which I am actually finally able to take, due to my having applied nose firmly to grindstone for the last month or so). I'll be back in a week, and I may be able to make a more substantial contribution at that time. Thanks, Joe, for taking the time to address the deficiencies in the grammar. I appreciate it. Derek From reinier at zwitserloot.com Mon Jul 27 23:55:19 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 28 Jul 2009 08:55:19 +0200 Subject: General community and Process Questions (blog comment followups) In-Reply-To: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Message-ID: <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> No, I think it realistically indicates nobody cares about underscores in numbers. I've reviewed in detail most of the coin reviews. Even the ones I don't like (perhaps /especially/ the ones I don't like). I'm ambivalent about those underscores. My only concern is the time they'll waste that could have gone to more meaningful additions to the language, though it seems like I overestimated the time sink :) On a different note: coindev as a whole isn't a good motivator, in my opinion. In the early phases, any proposal that wasn't specced out to the nines was sort-of discarded. However, discussion on woefully underspecced proposals still continued, which wasted a lot of time - time that could have been spent analysing e.g. the grammar of the underscores proposal. It also demotivates because with the continuing discussion, it seemed that much harder for your pet proposal to make it in the face of such a big list. In my opinion, coin was missing a step: The step where you make a case for a change not by submitting a complete coin proposal, but instead by showing why its neccessary, and why it will (likely) be implementable while retaining backwards compatibility. A list full of vehement support can always back out once it becomes obvious, when writing the full JLS changes and speccing out a grammar, that the change isn't nearly as simple as everyone thought at first. As a result of these negative effects, I'm guessing volunteer involvement wasn't nearly as large as you thought it might have been, Joe. fixing it in the future: - Be a dictator. It works, for programming languages. Reduce the amount of effort needed for round 1 of a proposal, but aggressively turn down and in fact forbid discussion on denied proposals (this isn't overreacting; coindev is the OFFICIAL list. If people want to discuss an underspecced proposal, they can do so elsewhere, and come back with a complete proposal submission). The amount of traffic on coindev was (at least for me) hard to keep up with. - Waaaaay more time. I don't see how any new java release can exclude language changes from the get go, so start the next project coin the day after the release of java7. With timespans of that magnitude, you can implement entirely different rules: Multiple rounds, where the round that occurs at the same timespan as where coin was to the release of java 7 absolutely requires a prototype and a JLS patch with chapter and verse. However, the first round can hold to the above concept: Just make a case for why a given language change is a good idea. coin had a conflicting agenda: Everything had to be done _fast_, but everything also had to be carefully deliberated, fully specced out. Of course it didn't work very well. The rules would then be simple: There's an agenda with minimum requirements, and any proposal that doesn't meet the minimum requirements at that point in time may NOT be discussed on the official list. - Any proposal can also be vetoed at any time, at which point the volunteers can stop their efforts and focus on other things. Veto proposals sooner rather than later to avoid wasting time. If you know it's just not going to get there, don't just say so, make it official. Keep a list of proposals 'still in the running', so to speak, and update it more often than twice throughout the entire process. --Reinier Zwitserloot On 2009/27/07, at 22:47, Derek Foster wrote: >>> coin contributions. For example, back in May there was an open >>> issue >>> concerning the grammar changes needed for underscores in numbers >>> [5]. >>> No one sent in a message on this matter until I sent in a grammar in >>> July [6]. Neither the coin list nor readers on my blog caught the >>> embarrassing but small mistake I made in the grammar [7]. In >>> terms of >>> difficulty of language evolution, this grammar change is easy. >>> Having >>> taken an undergraduate class in compilers or automata theory is >>> sufficient background to work on this, but no one else contributed a >>> grammar for this despite presumed interest in the feature and the >>> large >>> number of coin subscribers. >> >> May be this shown, that interest to number literals is relative >> small ? > > I think that this more realistically indicates that everybody > considers this someone else's problem to fix. (Presumably, mine, > since I submitted the original proposal.) > > Unfortunately, I have been slammed lately by an upcoming product > release at work as well as some issues in my personal life, and have > had little time to do much else other than try to at least read the > Project Coin list messages as they go by. I did put together an > initial draft of a fix to the issues Joe raised, but I didn't have > time to really run it through the wringer and analyze it for > problems, so I didn't submit it to the list yet. When Joe submitted > his fix, I was quite relieved that someone else had had the time to > do a more complete job of it, and I was planning to go over it in > detail, but I just haven't had time yet. > > This is unfortunately a risk of having work done by volunteers -- > since they aren't getting paid for the work they do, the work is > subject to being delayed due to work that people ARE paid to do. As > a result, realistically, extra time needs to be allocated for > volunteer-driven efforts, and/or some kind of structure needs to be > put in place so that if one person has trouble keeping up, that > others can shoulder the load in some sort of controlled fashion. > Right now, it is basically expected that whoever originally > submitted a proposal is responsible for shepherding it through every > distinct phase of its development, from proposal, to design, to > implementation, answering criticisms about it, revising it, > prototyping it, etc. etc. This is a LOT of work for one person. (It > also requires that a single person be skilled in every step of the > process, which requires a lot of different skills to be present in > one person. A rare mix, which is unfortunately a significant > limiting factor > on proposals.) Of course, people who are interested in the proposal > but not responsible for it are willing to offer criticisms, but not > necessarily help (since raising issues takes MUCH less time than > fixing them, after all). I think that this is a weakness of the > process that Coin is using, and one that should be addressed in a > future effort of this sort. > > In any case, this is all I have time to write at the moment, since I > am about to get in a car and take a much-needed vacation (which I am > actually finally able to take, due to my having applied nose firmly > to grindstone for the last month or so). I'll be back in a week, and > I may be able to make a more substantial contribution at that time. > > Thanks, Joe, for taking the time to address the deficiencies in the > grammar. I appreciate it. > > Derek > > From noel at peralex.com Tue Jul 28 04:35:01 2009 From: noel at peralex.com (Noel Grandin) Date: Tue, 28 Jul 2009 13:35:01 +0200 Subject: General community and Process Questions (blog comment followups) In-Reply-To: <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> References: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> Message-ID: <4A6EE265.3090106@peralex.com> further suggestions: Have a project wiki that provides a list of proposals, and for each proposal: - status (incoming, rejected, phase1, phase2) - links to relevant mailing list discussions - links to relevant documents Then people can get referred to the wiki to get an idea of what is going on. It might also be an idea to have a real project repository where each proposal lives in it's own branch, and has documents, examples, test-cases, scripts, code, etc. We __are__ programmers after all :-) For a first attempt, I think project coin has done pretty well, but like all things, it can be improved upon. Keep up the good work Joe. -- Noel Grandin. Reinier Zwitserloot wrote: > No, I think it realistically indicates nobody cares about underscores > in numbers. I've reviewed in detail most of the coin reviews. Even the > ones I don't like (perhaps /especially/ the ones I don't like). I'm > ambivalent about those underscores. My only concern is the time > they'll waste that could have gone to more meaningful additions to the > language, though it seems like I overestimated the time sink :) > > > On a different note: coindev as a whole isn't a good motivator, in my > opinion. > > In the early phases, any proposal that wasn't specced out to the nines > was sort-of discarded. However, discussion on woefully underspecced > proposals still continued, which wasted a lot of time - time that > could have been spent analysing e.g. the grammar of the underscores > proposal. It also demotivates because with the continuing discussion, > it seemed that much harder for your pet proposal to make it in the > face of such a big list. In my opinion, coin was missing a step: The > step where you make a case for a change not by submitting a complete > coin proposal, but instead by showing why its neccessary, and why it > will (likely) be implementable while retaining backwards > compatibility. A list full of vehement support can always back out > once it becomes obvious, when writing the full JLS changes and > speccing out a grammar, that the change isn't nearly as simple as > everyone thought at first. > > As a result of these negative effects, I'm guessing volunteer > involvement wasn't nearly as large as you thought it might have been, > Joe. > > fixing it in the future: > > - Be a dictator. It works, for programming languages. Reduce the > amount of effort needed for round 1 of a proposal, but aggressively > turn down and in fact forbid discussion on denied proposals (this > isn't overreacting; coindev is the OFFICIAL list. If people want to > discuss an underspecced proposal, they can do so elsewhere, and come > back with a complete proposal submission). The amount of traffic on > coindev was (at least for me) hard to keep up with. > > - Waaaaay more time. I don't see how any new java release can > exclude language changes from the get go, so start the next project > coin the day after the release of java7. With timespans of that > magnitude, you can implement entirely different rules: Multiple > rounds, where the round that occurs at the same timespan as where coin > was to the release of java 7 absolutely requires a prototype and a JLS > patch with chapter and verse. However, the first round can hold to the > above concept: Just make a case for why a given language change is a > good idea. coin had a conflicting agenda: Everything had to be done > _fast_, but everything also had to be carefully deliberated, fully > specced out. Of course it didn't work very well. The rules would then > be simple: There's an agenda with minimum requirements, and any > proposal that doesn't meet the minimum requirements at that point in > time may NOT be discussed on the official list. > > - Any proposal can also be vetoed at any time, at which point the > volunteers can stop their efforts and focus on other things. Veto > proposals sooner rather than later to avoid wasting time. If you know > it's just not going to get there, don't just say so, make it official. > Keep a list of proposals 'still in the running', so to speak, and > update it more often than twice throughout the entire process. > > --Reinier Zwitserloot > > > > On 2009/27/07, at 22:47, Derek Foster wrote: > > >>>> coin contributions. For example, back in May there was an open >>>> issue >>>> concerning the grammar changes needed for underscores in numbers >>>> [5]. >>>> No one sent in a message on this matter until I sent in a grammar in >>>> July [6]. Neither the coin list nor readers on my blog caught the >>>> embarrassing but small mistake I made in the grammar [7]. In >>>> terms of >>>> difficulty of language evolution, this grammar change is easy. >>>> Having >>>> taken an undergraduate class in compilers or automata theory is >>>> sufficient background to work on this, but no one else contributed a >>>> grammar for this despite presumed interest in the feature and the >>>> large >>>> number of coin subscribers. >>>> >>> May be this shown, that interest to number literals is relative >>> small ? >>> >> I think that this more realistically indicates that everybody >> considers this someone else's problem to fix. (Presumably, mine, >> since I submitted the original proposal.) >> >> Unfortunately, I have been slammed lately by an upcoming product >> release at work as well as some issues in my personal life, and have >> had little time to do much else other than try to at least read the >> Project Coin list messages as they go by. I did put together an >> initial draft of a fix to the issues Joe raised, but I didn't have >> time to really run it through the wringer and analyze it for >> problems, so I didn't submit it to the list yet. When Joe submitted >> his fix, I was quite relieved that someone else had had the time to >> do a more complete job of it, and I was planning to go over it in >> detail, but I just haven't had time yet. >> >> This is unfortunately a risk of having work done by volunteers -- >> since they aren't getting paid for the work they do, the work is >> subject to being delayed due to work that people ARE paid to do. As >> a result, realistically, extra time needs to be allocated for >> volunteer-driven efforts, and/or some kind of structure needs to be >> put in place so that if one person has trouble keeping up, that >> others can shoulder the load in some sort of controlled fashion. >> Right now, it is basically expected that whoever originally >> submitted a proposal is responsible for shepherding it through every >> distinct phase of its development, from proposal, to design, to >> implementation, answering criticisms about it, revising it, >> prototyping it, etc. etc. This is a LOT of work for one person. (It >> also requires that a single person be skilled in every step of the >> process, which requires a lot of different skills to be present in >> one person. A rare mix, which is unfortunately a significant >> limiting factor >> on proposals.) Of course, people who are interested in the proposal >> but not responsible for it are willing to offer criticisms, but not >> necessarily help (since raising issues takes MUCH less time than >> fixing them, after all). I think that this is a weakness of the >> process that Coin is using, and one that should be addressed in a >> future effort of this sort. >> >> In any case, this is all I have time to write at the moment, since I >> am about to get in a car and take a much-needed vacation (which I am >> actually finally able to take, due to my having applied nose firmly >> to grindstone for the last month or so). I'll be back in a week, and >> I may be able to make a more substantial contribution at that time. >> >> Thanks, Joe, for taking the time to address the deficiencies in the >> grammar. I appreciate it. >> >> Derek >> >> >> > > > > Disclaimer: http://www.peralex.com/disclaimer.html From reinier at zwitserloot.com Tue Jul 28 05:59:13 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 28 Jul 2009 14:59:13 +0200 Subject: General community and Process Questions (blog comment followups) In-Reply-To: <4A6EE265.3090106@peralex.com> References: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> <4A6EE265.3090106@peralex.com> Message-ID: <15F136FC-BFD2-42B8-9BC0-38EEBD49D57C@zwitserloot.com> Good points, Noel. One of the things I forgot to mention: From time to time, discussion went in circles; I presume because not everyone felt up to the task of reading through the backlog of the coindev list (due to the sheer amount of traffic, I can't really blame them). A wiki would be a much nicer format, and by way of the wiki history function, you would _still_ have a time-based history of how the community decided on a certain change, which is one of the stated goals of the coindev mailing list. --Reinier Zwitserloot Like it? Tip it! http://tipit.to On 2009/28/07, at 13:35, Noel Grandin wrote: > > further suggestions: > > Have a project wiki that provides a list of proposals, and for each > proposal: > - status (incoming, rejected, phase1, phase2) > - links to relevant mailing list discussions > - links to relevant documents > > Then people can get referred to the wiki to get an idea of what is > going on. > > It might also be an idea to have a real project repository where each > proposal lives in it's own branch, and has documents, examples, > test-cases, scripts, code, etc. > We __are__ programmers after all :-) > > For a first attempt, I think project coin has done pretty well, but > like > all things, it can be improved upon. > > Keep up the good work Joe. > > -- Noel Grandin. > > > Reinier Zwitserloot wrote: >> No, I think it realistically indicates nobody cares about underscores >> in numbers. I've reviewed in detail most of the coin reviews. Even >> the >> ones I don't like (perhaps /especially/ the ones I don't like). I'm >> ambivalent about those underscores. My only concern is the time >> they'll waste that could have gone to more meaningful additions to >> the >> language, though it seems like I overestimated the time sink :) >> >> >> On a different note: coindev as a whole isn't a good motivator, in my >> opinion. >> >> In the early phases, any proposal that wasn't specced out to the >> nines >> was sort-of discarded. However, discussion on woefully underspecced >> proposals still continued, which wasted a lot of time - time that >> could have been spent analysing e.g. the grammar of the underscores >> proposal. It also demotivates because with the continuing discussion, >> it seemed that much harder for your pet proposal to make it in the >> face of such a big list. In my opinion, coin was missing a step: The >> step where you make a case for a change not by submitting a complete >> coin proposal, but instead by showing why its neccessary, and why it >> will (likely) be implementable while retaining backwards >> compatibility. A list full of vehement support can always back out >> once it becomes obvious, when writing the full JLS changes and >> speccing out a grammar, that the change isn't nearly as simple as >> everyone thought at first. >> >> As a result of these negative effects, I'm guessing volunteer >> involvement wasn't nearly as large as you thought it might have been, >> Joe. >> >> fixing it in the future: >> >> - Be a dictator. It works, for programming languages. Reduce the >> amount of effort needed for round 1 of a proposal, but aggressively >> turn down and in fact forbid discussion on denied proposals (this >> isn't overreacting; coindev is the OFFICIAL list. If people want to >> discuss an underspecced proposal, they can do so elsewhere, and come >> back with a complete proposal submission). The amount of traffic on >> coindev was (at least for me) hard to keep up with. >> >> - Waaaaay more time. I don't see how any new java release can >> exclude language changes from the get go, so start the next project >> coin the day after the release of java7. With timespans of that >> magnitude, you can implement entirely different rules: Multiple >> rounds, where the round that occurs at the same timespan as where >> coin >> was to the release of java 7 absolutely requires a prototype and a >> JLS >> patch with chapter and verse. However, the first round can hold to >> the >> above concept: Just make a case for why a given language change is a >> good idea. coin had a conflicting agenda: Everything had to be done >> _fast_, but everything also had to be carefully deliberated, fully >> specced out. Of course it didn't work very well. The rules would then >> be simple: There's an agenda with minimum requirements, and any >> proposal that doesn't meet the minimum requirements at that point in >> time may NOT be discussed on the official list. >> >> - Any proposal can also be vetoed at any time, at which point the >> volunteers can stop their efforts and focus on other things. Veto >> proposals sooner rather than later to avoid wasting time. If you know >> it's just not going to get there, don't just say so, make it >> official. >> Keep a list of proposals 'still in the running', so to speak, and >> update it more often than twice throughout the entire process. >> >> --Reinier Zwitserloot >> >> >> >> On 2009/27/07, at 22:47, Derek Foster wrote: >> >> >>>>> coin contributions. For example, back in May there was an open >>>>> issue >>>>> concerning the grammar changes needed for underscores in numbers >>>>> [5]. >>>>> No one sent in a message on this matter until I sent in a >>>>> grammar in >>>>> July [6]. Neither the coin list nor readers on my blog caught >>>>> the >>>>> embarrassing but small mistake I made in the grammar [7]. In >>>>> terms of >>>>> difficulty of language evolution, this grammar change is easy. >>>>> Having >>>>> taken an undergraduate class in compilers or automata theory is >>>>> sufficient background to work on this, but no one else >>>>> contributed a >>>>> grammar for this despite presumed interest in the feature and the >>>>> large >>>>> number of coin subscribers. >>>>> >>>> May be this shown, that interest to number literals is relative >>>> small ? >>>> >>> I think that this more realistically indicates that everybody >>> considers this someone else's problem to fix. (Presumably, mine, >>> since I submitted the original proposal.) >>> >>> Unfortunately, I have been slammed lately by an upcoming product >>> release at work as well as some issues in my personal life, and have >>> had little time to do much else other than try to at least read the >>> Project Coin list messages as they go by. I did put together an >>> initial draft of a fix to the issues Joe raised, but I didn't have >>> time to really run it through the wringer and analyze it for >>> problems, so I didn't submit it to the list yet. When Joe submitted >>> his fix, I was quite relieved that someone else had had the time to >>> do a more complete job of it, and I was planning to go over it in >>> detail, but I just haven't had time yet. >>> >>> This is unfortunately a risk of having work done by volunteers -- >>> since they aren't getting paid for the work they do, the work is >>> subject to being delayed due to work that people ARE paid to do. As >>> a result, realistically, extra time needs to be allocated for >>> volunteer-driven efforts, and/or some kind of structure needs to be >>> put in place so that if one person has trouble keeping up, that >>> others can shoulder the load in some sort of controlled fashion. >>> Right now, it is basically expected that whoever originally >>> submitted a proposal is responsible for shepherding it through every >>> distinct phase of its development, from proposal, to design, to >>> implementation, answering criticisms about it, revising it, >>> prototyping it, etc. etc. This is a LOT of work for one person. (It >>> also requires that a single person be skilled in every step of the >>> process, which requires a lot of different skills to be present in >>> one person. A rare mix, which is unfortunately a significant >>> limiting factor >>> on proposals.) Of course, people who are interested in the proposal >>> but not responsible for it are willing to offer criticisms, but not >>> necessarily help (since raising issues takes MUCH less time than >>> fixing them, after all). I think that this is a weakness of the >>> process that Coin is using, and one that should be addressed in a >>> future effort of this sort. >>> >>> In any case, this is all I have time to write at the moment, since I >>> am about to get in a car and take a much-needed vacation (which I am >>> actually finally able to take, due to my having applied nose firmly >>> to grindstone for the last month or so). I'll be back in a week, and >>> I may be able to make a more substantial contribution at that time. >>> >>> Thanks, Joe, for taking the time to address the deficiencies in the >>> grammar. I appreciate it. >>> >>> Derek >>> >>> >>> >> >> >> >> > > > Disclaimer: http://www.peralex.com/disclaimer.html > > > From neal at gafter.com Tue Jul 28 07:35:15 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 28 Jul 2009 07:35:15 -0700 Subject: General community and Process Questions (blog comment followups) In-Reply-To: <4A6EE265.3090106@peralex.com> References: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> <4A6EE265.3090106@peralex.com> Message-ID: <15e8b9d20907280735l6567b8c7y4f9e8e513848f1c9@mail.gmail.com> Noel- This is a great idea; it would certainly help casual observers to follow the status of the proposals and discussion. That would also be useful as a starting point for any future Coin-like project. I volunteer to provide web hosting and software support if you'll agree to set up and maintain the Wiki based on the existing discussion record. Please let me know. Cheers, Neal On Tue, Jul 28, 2009 at 4:35 AM, Noel Grandin wrote: > > further suggestions: > > Have a project wiki that provides a list of proposals, and for each > proposal: > - status (incoming, rejected, phase1, phase2) > - links to relevant mailing list discussions > - links to relevant documents > > Then people can get referred to the wiki to get an idea of what is going > on. > > It might also be an idea to have a real project repository where each > proposal lives in it's own branch, and has documents, examples, > test-cases, scripts, code, etc. > We __are__ programmers after all :-) > > For a first attempt, I think project coin has done pretty well, but like > all things, it can be improved upon. > > Keep up the good work Joe. > > -- Noel Grandin. > > > Reinier Zwitserloot wrote: > > No, I think it realistically indicates nobody cares about underscores > > in numbers. I've reviewed in detail most of the coin reviews. Even the > > ones I don't like (perhaps /especially/ the ones I don't like). I'm > > ambivalent about those underscores. My only concern is the time > > they'll waste that could have gone to more meaningful additions to the > > language, though it seems like I overestimated the time sink :) > > > > > > On a different note: coindev as a whole isn't a good motivator, in my > > opinion. > > > > In the early phases, any proposal that wasn't specced out to the nines > > was sort-of discarded. However, discussion on woefully underspecced > > proposals still continued, which wasted a lot of time - time that > > could have been spent analysing e.g. the grammar of the underscores > > proposal. It also demotivates because with the continuing discussion, > > it seemed that much harder for your pet proposal to make it in the > > face of such a big list. In my opinion, coin was missing a step: The > > step where you make a case for a change not by submitting a complete > > coin proposal, but instead by showing why its neccessary, and why it > > will (likely) be implementable while retaining backwards > > compatibility. A list full of vehement support can always back out > > once it becomes obvious, when writing the full JLS changes and > > speccing out a grammar, that the change isn't nearly as simple as > > everyone thought at first. > > > > As a result of these negative effects, I'm guessing volunteer > > involvement wasn't nearly as large as you thought it might have been, > > Joe. > > > > fixing it in the future: > > > > - Be a dictator. It works, for programming languages. Reduce the > > amount of effort needed for round 1 of a proposal, but aggressively > > turn down and in fact forbid discussion on denied proposals (this > > isn't overreacting; coindev is the OFFICIAL list. If people want to > > discuss an underspecced proposal, they can do so elsewhere, and come > > back with a complete proposal submission). The amount of traffic on > > coindev was (at least for me) hard to keep up with. > > > > - Waaaaay more time. I don't see how any new java release can > > exclude language changes from the get go, so start the next project > > coin the day after the release of java7. With timespans of that > > magnitude, you can implement entirely different rules: Multiple > > rounds, where the round that occurs at the same timespan as where coin > > was to the release of java 7 absolutely requires a prototype and a JLS > > patch with chapter and verse. However, the first round can hold to the > > above concept: Just make a case for why a given language change is a > > good idea. coin had a conflicting agenda: Everything had to be done > > _fast_, but everything also had to be carefully deliberated, fully > > specced out. Of course it didn't work very well. The rules would then > > be simple: There's an agenda with minimum requirements, and any > > proposal that doesn't meet the minimum requirements at that point in > > time may NOT be discussed on the official list. > > > > - Any proposal can also be vetoed at any time, at which point the > > volunteers can stop their efforts and focus on other things. Veto > > proposals sooner rather than later to avoid wasting time. If you know > > it's just not going to get there, don't just say so, make it official. > > Keep a list of proposals 'still in the running', so to speak, and > > update it more often than twice throughout the entire process. > > > > --Reinier Zwitserloot > > > > > > > > On 2009/27/07, at 22:47, Derek Foster wrote: > > > > > >>>> coin contributions. For example, back in May there was an open > >>>> issue > >>>> concerning the grammar changes needed for underscores in numbers > >>>> [5]. > >>>> No one sent in a message on this matter until I sent in a grammar in > >>>> July [6]. Neither the coin list nor readers on my blog caught the > >>>> embarrassing but small mistake I made in the grammar [7]. In > >>>> terms of > >>>> difficulty of language evolution, this grammar change is easy. > >>>> Having > >>>> taken an undergraduate class in compilers or automata theory is > >>>> sufficient background to work on this, but no one else contributed a > >>>> grammar for this despite presumed interest in the feature and the > >>>> large > >>>> number of coin subscribers. > >>>> > >>> May be this shown, that interest to number literals is relative > >>> small ? > >>> > >> I think that this more realistically indicates that everybody > >> considers this someone else's problem to fix. (Presumably, mine, > >> since I submitted the original proposal.) > >> > >> Unfortunately, I have been slammed lately by an upcoming product > >> release at work as well as some issues in my personal life, and have > >> had little time to do much else other than try to at least read the > >> Project Coin list messages as they go by. I did put together an > >> initial draft of a fix to the issues Joe raised, but I didn't have > >> time to really run it through the wringer and analyze it for > >> problems, so I didn't submit it to the list yet. When Joe submitted > >> his fix, I was quite relieved that someone else had had the time to > >> do a more complete job of it, and I was planning to go over it in > >> detail, but I just haven't had time yet. > >> > >> This is unfortunately a risk of having work done by volunteers -- > >> since they aren't getting paid for the work they do, the work is > >> subject to being delayed due to work that people ARE paid to do. As > >> a result, realistically, extra time needs to be allocated for > >> volunteer-driven efforts, and/or some kind of structure needs to be > >> put in place so that if one person has trouble keeping up, that > >> others can shoulder the load in some sort of controlled fashion. > >> Right now, it is basically expected that whoever originally > >> submitted a proposal is responsible for shepherding it through every > >> distinct phase of its development, from proposal, to design, to > >> implementation, answering criticisms about it, revising it, > >> prototyping it, etc. etc. This is a LOT of work for one person. (It > >> also requires that a single person be skilled in every step of the > >> process, which requires a lot of different skills to be present in > >> one person. A rare mix, which is unfortunately a significant > >> limiting factor > >> on proposals.) Of course, people who are interested in the proposal > >> but not responsible for it are willing to offer criticisms, but not > >> necessarily help (since raising issues takes MUCH less time than > >> fixing them, after all). I think that this is a weakness of the > >> process that Coin is using, and one that should be addressed in a > >> future effort of this sort. > >> > >> In any case, this is all I have time to write at the moment, since I > >> am about to get in a car and take a much-needed vacation (which I am > >> actually finally able to take, due to my having applied nose firmly > >> to grindstone for the last month or so). I'll be back in a week, and > >> I may be able to make a more substantial contribution at that time. > >> > >> Thanks, Joe, for taking the time to address the deficiencies in the > >> grammar. I appreciate it. > >> > >> Derek > >> > >> > >> > > > > > > > > > > > Disclaimer: http://www.peralex.com/disclaimer.html > > > > From rssh at gradsoft.com.ua Tue Jul 28 08:12:47 2009 From: rssh at gradsoft.com.ua (Ruslan Shevchenko) Date: Tue, 28 Jul 2009 18:12:47 +0300 (EEST) Subject: General community and Process Questions (blog comment followups) In-Reply-To: <15F136FC-BFD2-42B8-9BC0-38EEBD49D57C@zwitserloot.com> References: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> <4A6EE265.3090106@peralex.com> <15F136FC-BFD2-42B8-9BC0-38EEBD49D57C@zwitserloot.com> Message-ID: <4bf2a2c411388ef1afd839e19af233c8.squirrel@wmail.gradsoft.ua> +1 for wiki in next coin versions (if will exists). //can count me as volunteer, which can setup redmine or xwiki if needed. From Joe.Darcy at Sun.COM Tue Jul 28 08:52:05 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 28 Jul 2009 08:52:05 -0700 Subject: General community and Process Questions (blog comment followups) In-Reply-To: <15e8b9d20907280735l6567b8c7y4f9e8e513848f1c9@mail.gmail.com> References: <6013007.1248727620865.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <6713E780-FBF4-45F2-8CAD-96A223EB8BFD@zwitserloot.com> <4A6EE265.3090106@peralex.com> <15e8b9d20907280735l6567b8c7y4f9e8e513848f1c9@mail.gmail.com> Message-ID: <4A6F1EA5.1000709@sun.com> Neal Gafter wrote: > Noel- > > This is a great idea; it would certainly help casual observers to follow the > status of the proposals and discussion. That would also be useful as a > starting point for any future Coin-like project. > > I volunteer to provide web hosting and software support if you'll agree to > set up and maintain the Wiki based on the existing discussion record. > Please let me know. > I can set up a wiki under http://wikis.sun.com, as done for the Da Vinci Machine Project (the JSR 292 RI). However, I will not actively maintain a wiki so someone else would have to volunteer to do this work. Additionally, one purpose of my Coin blog posts is to provide a lower volume way to track what is going on; posts under http://blogs.sun.com/main/tags/projectcoin provide news of major developments and links to the latest versions of proposals, etc. -Joe > Cheers, > Neal > > On Tue, Jul 28, 2009 at 4:35 AM, Noel Grandin wrote: > > >> further suggestions: >> >> Have a project wiki that provides a list of proposals, and for each >> proposal: >> - status (incoming, rejected, phase1, phase2) >> - links to relevant mailing list discussions >> - links to relevant documents >> >> Then people can get referred to the wiki to get an idea of what is going >> on. >> >> It might also be an idea to have a real project repository where each >> proposal lives in it's own branch, and has documents, examples, >> test-cases, scripts, code, etc. >> We __are__ programmers after all :-) >> >> For a first attempt, I think project coin has done pretty well, but like >> all things, it can be improved upon. >> >> Keep up the good work Joe. >> >> -- Noel Grandin. >> >> >> Reinier Zwitserloot wrote: >> >>> No, I think it realistically indicates nobody cares about underscores >>> in numbers. I've reviewed in detail most of the coin reviews. Even the >>> ones I don't like (perhaps /especially/ the ones I don't like). I'm >>> ambivalent about those underscores. My only concern is the time >>> they'll waste that could have gone to more meaningful additions to the >>> language, though it seems like I overestimated the time sink :) >>> >>> >>> On a different note: coindev as a whole isn't a good motivator, in my >>> opinion. >>> >>> In the early phases, any proposal that wasn't specced out to the nines >>> was sort-of discarded. However, discussion on woefully underspecced >>> proposals still continued, which wasted a lot of time - time that >>> could have been spent analysing e.g. the grammar of the underscores >>> proposal. It also demotivates because with the continuing discussion, >>> it seemed that much harder for your pet proposal to make it in the >>> face of such a big list. In my opinion, coin was missing a step: The >>> step where you make a case for a change not by submitting a complete >>> coin proposal, but instead by showing why its neccessary, and why it >>> will (likely) be implementable while retaining backwards >>> compatibility. A list full of vehement support can always back out >>> once it becomes obvious, when writing the full JLS changes and >>> speccing out a grammar, that the change isn't nearly as simple as >>> everyone thought at first. >>> >>> As a result of these negative effects, I'm guessing volunteer >>> involvement wasn't nearly as large as you thought it might have been, >>> Joe. >>> >>> fixing it in the future: >>> >>> - Be a dictator. It works, for programming languages. Reduce the >>> amount of effort needed for round 1 of a proposal, but aggressively >>> turn down and in fact forbid discussion on denied proposals (this >>> isn't overreacting; coindev is the OFFICIAL list. If people want to >>> discuss an underspecced proposal, they can do so elsewhere, and come >>> back with a complete proposal submission). The amount of traffic on >>> coindev was (at least for me) hard to keep up with. >>> >>> - Waaaaay more time. I don't see how any new java release can >>> exclude language changes from the get go, so start the next project >>> coin the day after the release of java7. With timespans of that >>> magnitude, you can implement entirely different rules: Multiple >>> rounds, where the round that occurs at the same timespan as where coin >>> was to the release of java 7 absolutely requires a prototype and a JLS >>> patch with chapter and verse. However, the first round can hold to the >>> above concept: Just make a case for why a given language change is a >>> good idea. coin had a conflicting agenda: Everything had to be done >>> _fast_, but everything also had to be carefully deliberated, fully >>> specced out. Of course it didn't work very well. The rules would then >>> be simple: There's an agenda with minimum requirements, and any >>> proposal that doesn't meet the minimum requirements at that point in >>> time may NOT be discussed on the official list. >>> >>> - Any proposal can also be vetoed at any time, at which point the >>> volunteers can stop their efforts and focus on other things. Veto >>> proposals sooner rather than later to avoid wasting time. If you know >>> it's just not going to get there, don't just say so, make it official. >>> Keep a list of proposals 'still in the running', so to speak, and >>> update it more often than twice throughout the entire process. >>> >>> --Reinier Zwitserloot >>> >>> >>> >>> On 2009/27/07, at 22:47, Derek Foster wrote: >>> >>> >>> >>>>>> coin contributions. For example, back in May there was an open >>>>>> issue >>>>>> concerning the grammar changes needed for underscores in numbers >>>>>> [5]. >>>>>> No one sent in a message on this matter until I sent in a grammar in >>>>>> July [6]. Neither the coin list nor readers on my blog caught the >>>>>> embarrassing but small mistake I made in the grammar [7]. In >>>>>> terms of >>>>>> difficulty of language evolution, this grammar change is easy. >>>>>> Having >>>>>> taken an undergraduate class in compilers or automata theory is >>>>>> sufficient background to work on this, but no one else contributed a >>>>>> grammar for this despite presumed interest in the feature and the >>>>>> large >>>>>> number of coin subscribers. >>>>>> >>>>>> >>>>> May be this shown, that interest to number literals is relative >>>>> small ? >>>>> >>>>> >>>> I think that this more realistically indicates that everybody >>>> considers this someone else's problem to fix. (Presumably, mine, >>>> since I submitted the original proposal.) >>>> >>>> Unfortunately, I have been slammed lately by an upcoming product >>>> release at work as well as some issues in my personal life, and have >>>> had little time to do much else other than try to at least read the >>>> Project Coin list messages as they go by. I did put together an >>>> initial draft of a fix to the issues Joe raised, but I didn't have >>>> time to really run it through the wringer and analyze it for >>>> problems, so I didn't submit it to the list yet. When Joe submitted >>>> his fix, I was quite relieved that someone else had had the time to >>>> do a more complete job of it, and I was planning to go over it in >>>> detail, but I just haven't had time yet. >>>> >>>> This is unfortunately a risk of having work done by volunteers -- >>>> since they aren't getting paid for the work they do, the work is >>>> subject to being delayed due to work that people ARE paid to do. As >>>> a result, realistically, extra time needs to be allocated for >>>> volunteer-driven efforts, and/or some kind of structure needs to be >>>> put in place so that if one person has trouble keeping up, that >>>> others can shoulder the load in some sort of controlled fashion. >>>> Right now, it is basically expected that whoever originally >>>> submitted a proposal is responsible for shepherding it through every >>>> distinct phase of its development, from proposal, to design, to >>>> implementation, answering criticisms about it, revising it, >>>> prototyping it, etc. etc. This is a LOT of work for one person. (It >>>> also requires that a single person be skilled in every step of the >>>> process, which requires a lot of different skills to be present in >>>> one person. A rare mix, which is unfortunately a significant >>>> limiting factor >>>> on proposals.) Of course, people who are interested in the proposal >>>> but not responsible for it are willing to offer criticisms, but not >>>> necessarily help (since raising issues takes MUCH less time than >>>> fixing them, after all). I think that this is a weakness of the >>>> process that Coin is using, and one that should be addressed in a >>>> future effort of this sort. >>>> >>>> In any case, this is all I have time to write at the moment, since I >>>> am about to get in a car and take a much-needed vacation (which I am >>>> actually finally able to take, due to my having applied nose firmly >>>> to grindstone for the last month or so). I'll be back in a week, and >>>> I may be able to make a more substantial contribution at that time. >>>> >>>> Thanks, Joe, for taking the time to address the deficiencies in the >>>> grammar. I appreciate it. >>>> >>>> Derek >>>> >>>> >>>> >>>> >>> >>> >>> >> Disclaimer: http://www.peralex.com/disclaimer.html >> >> >> >> >> > > From reinier at zwitserloot.com Tue Jul 28 17:36:58 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 29 Jul 2009 02:36:58 +0200 Subject: Prototype that covers ARM, auto-generating boilerplate, even SneakyThrows, AND it works in eclipse. Message-ID: <4A48EDB7-4383-4678-BDC3-153AE1D736F2@zwitserloot.com> Hey guys, Well, 'prototype' isn't entirely correct: Because of the glacial pace of java updates, Project Lombok (the 'prototype') is meant as a real world java plugin, to be used anywhere, including production environments. Still, it's one way to get more familiar with some of the coin proposals, most notably ARM, as its still on the shortlist. Unlike any other prototype, this one works seamlessly in current eclipse and javac distributions, without requiring modifying any of those files. In my opinion, eclipse (or any other IDE) support is _crucial_ - prototypes without IDE support won't give you a real feel for a feature, as nobody (sane) programs java without the help of a smart editor. The few souls that program without the help of auto- completion, error checking as you type, and easy navigation around your codebase, has jumped ship to python or ruby a loooong time ago. It's a long story, so maybe you'd rather just watch the less-than-4- minute screencast than read on: http://projectlombok.org/ What's in there right now: ARM: It's not quite like Josh's proposal, as Project Lombok works on the existing parser architecture. Here's some sample code. Yes, that's an annotation being used as a language feature. Sue me. It works, it's namespaced, and it's one click away from helpful javadoc, and, Neal, you'll like this: It's in a library! void copy(String from, String to) throws IOException { @Cleanup InputStream in = new FileInputStream(from); @Cleanup OutputStream out = new FileOutputStream(to); byte[] b = new byte[10000]; while (true) { int r = in.read(b); if (r == -1) break; out.write(b, 0, r); } } It works by replacing all statements BELOW a @Cleanup annotated local variable declaration, all the way up to the end of that scope, with a try statement that runs those statements in the try block, and as a finally block, calls a method named "close" with no arguments on the variable. You can also pick another method to call, by specifying it as a parameter, like so: @Cleanup("dispose") CoolBar someSwtWidget = new CoolBar(); Note that it does NOT attempt to 'hide' exceptions from the close method if the try body also throws an exception, simply because you just can't get there with syntax sugar. We'd like to, though. Elimination of vast tracts of boilerplate: @Getter will generate a getter. @Setter will generate a setter (on fields). @EqualsAndHashCode will generate an equals and hashCode implementation using all non-static, non-transient fields, and is smart enough to use Arrays.deepHashCode where neccessary, for example. @ToString generates a toString, and if you want all of those at once, "@Data" bundles all of that: equals, hashCode, toString, getters for all fields, setters for all non-final fields, and you also get a constructor that initializes all final fields. Example: @Data public class Point { private final int x, y; } What would you rather read (let alone type)? The above 3 lines, or the more than 70 lines that it would take to do it 'right', currently? I know Joe took this kind of boilerplate busting off the table for project coin, but working with Project Lombok on my own source code, @Data is pure heaven. SneakyThrows: Yes, I know this entire list hated the idea, but it's our project. @SneakyThrows is just like throws, except you don't have to catch or 'throw onward' the exceptions when you call a method with @SneakyThrows. Example: @SneakyThrows(UnsupportedEncodingException.class) public static String fromUTF8(byte[] b) { //return new String(b, Charset.forName("UTF-8")) WOULD work, but doesn't work on java 5 VMs. return new String(b, "UTF-8"); } new Thread(new Runnable() { @SneakyThrows public void run() { //run() should have thrown Throwable, but, backwards compatibility means that'll never ever get fixed. //with @SneakyThrows, that's not a problem any longer. throw new Throwable(); } }); The last one: @Synchronized. The actual 'synchronized' keyword on a method will lock on either 'this' or on the class object, depending on whether the method is static. This is nice in some cases, but more often you want to lock on a private field. There's even a java puzzler on the topic. With @Synchronized, a private field named \$lock is generated, and the entire method body is guarded by that lock instead. Also works with static methods (static \$LOCK is generated), and you can specify your own lock (though in that case, you'll have to write the field yourself) as well. The current set of transformations are all triggered by annotations, but this isn't required, and Project Lombok can be extended with your own transformations, which could for example trigger on a special method call. Could be useful for writing your own prototypes. As you'll see in the video, the eclipse integration goes MUCH further than ordinary annotation processors: The moment you finish typing the 'r' on a @Getter annotation, the getter _immediately_ appears in your outline view. "Find declaration" will even jump to the annotation that generated the method! The javac integration is nice as well: You just need to put lombok.jar in the classpath as you compile. That's it - no need to change javac or download a prototype compiler at all. Just: javac -cp lombok.jar *.java Only requirement: It has to be javac v1.6. -target 1.5 works just fine, though, and when using lombok with eclipse, you can use eclipse 3.4 or 3.5, and run eclipse on java5 or java6. So, don't wait for java 7 to be released, and start enjoying the benefits of ARM and getting rid of your boilerplate right now - http://projectlombok.org/ --Reinier Zwitserloot and Roel Spilker From tim at peierls.net Wed Jul 29 05:05:14 2009 From: tim at peierls.net (Tim Peierls) Date: Wed, 29 Jul 2009 08:05:14 -0400 Subject: Prototype that covers ARM, auto-generating boilerplate, even SneakyThrows, AND it works in eclipse. In-Reply-To: <4A48EDB7-4383-4678-BDC3-153AE1D736F2@zwitserloot.com> References: <4A48EDB7-4383-4678-BDC3-153AE1D736F2@zwitserloot.com> Message-ID: <63b4e4050907290505s25f0e827x4844f7e501f66530@mail.gmail.com> On Tue, Jul 28, 2009 at 8:36 PM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > ... nobody (sane) programs java without the help of a smart editor. The few > souls that program without the help of auto-completion, error checking as > you type, and easy navigation around your codebase, has jumped ship to > python or ruby a loooong time ago. This is the sound of me not jumping ship ... Sorry to hear that you question my sanity. :-) --tim