From hjohn at xs4all.nl Thu Oct 1 00:21:18 2009 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 01 Oct 2009 09:21:18 +0200 Subject: literals In-Reply-To: <326620.4804.qm@web112309.mail.gq1.yahoo.com> References: <326620.4804.qm@web112309.mail.gq1.yahoo.com> Message-ID: <4AC4586E.8020400@xs4all.nl> It will depend a lot on the relative speed of equals vs hashcode. Objects with fast hashcode functions but slow equals functions will perform relatively good in Sets, while the other way around will favor Lists. That said, the difference between the two functions would have to be huge to favor a List for any relevant amount of elements. Contains in Set, calls hashcode once and equals atleast once. With a decent hash function and the default load factor it is rare that equals is called a second time for the contains operation. Contains in List will call equals size / 2 times on average. --John Gene Ray wrote: > Reinier-- > > I benchmarked this, and appear to have arrived at > different results than you. I used lists/sets of 10-character strings > of lowercase letters, which is close a lot of use-cases I've seen, and > ran 10^7 trials for each implementation (I used HashSet/ArrayList). > For 20 elements, set was a little over 3x faster (891 ms vs 2906 ms); > for 7 elements set was still close to twice as fast (872/1550); for 2 > elements set was still slightly faster (859/969). List was indeed > faster with only one element (906/844), but at this point, I personally > would just be using the .equals method instead. Varying the string > length (I tried 5, 20, and 50) increased or decreased overall times > slightly, but did not affect relative performance. I would be curious > to learn what you benchmarked against. > > The above was done with > jdk1.6.0_12-b04, according to java -version. > > > Perfomance > is not the only concern. "Sets" in java represent the mathematical > notion of a set; lists do not, and pretending that the latter is > equivalent to the former is a logical error regardless of common practice. > > > >> NB: Gene, you're trying to argue that a _literal_ set is >> going to make >> some sort of speed difference compared to a a_literal_ >> list. That >> notion is frankly ridiculous. You also lost track of the >> first rule of >> discussing speed: Test it first. So, go ahead. Benchmark a >> bunch >> of .contains() calls on a list and a set with the same >> items in it, >> both with say, 20 items in them (we are talking about >> literals, after >> all. I don't think anyone is seriously considering sticking >> hundreds >> of lines of code in a >> > .java file to store constant data!) > >> - on my own >> machine Lists are less than a factor of 2 slower. For about >> 7 items >> and down, lists are in fact faster. Also, just in case >> someone IS >> tempted to write such a large collections literal: For such >> a large >> literal, the added burden of wrapping the literal in a >> "new >> HashSet<>()" or sticking a ".toSet();" at the end >> seems trivial. >> >> I think the 'set literals are rare' seem to have it, so I >> repeat my >> plea to the set literal fans: Give us some proof they >> aren't rare. >> Given that set literals cause so much pain, the burden is >> clearly on >> the supporters of a set literal to prove why we need them. >> >> --Reinier Zwitserloot >> >> >> >> On 2009/29/09, at >> > 21:07, Gene Ray wrote: > >>> "Rare"? >>> >>> In my experience, Sets are not rare in well-written >>> >> code; they're >> >>> only rare in code where for whatever reason the >>> >> developer has >> >>> refused to use them, and instead expends effort and >>> >> CPU time >> >>> iterating through an array or ArrayList to achieve the >>> >> equivalent >> >>> functionality. Encouraging this sort of behavior >>> >> further by >> >>> including only Lists in the new syntax is not a good >>> >> plan. >> > > > > > > From reinier at zwitserloot.com Thu Oct 1 06:25:56 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 1 Oct 2009 15:25:56 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <885297.56444.qm@web112304.mail.gq1.yahoo.com> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> Message-ID: <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> How is a mere constant factor of 3 relevant when the set/list contains so few entries? Writing code with performance in mind before you actually run into a performance problem is bad, but designing the language with this in mind is undoubtedly worse. In the extremely rare cases where this speed issue is relevant, the burden of converting that list to a set remains a drop in the bucket compared to the other hoops one would normally have to jump through in order to solve a performance problem. I have absolutely no idea why 'speed' is being put on the table here as an argument in favour of set literals. I suggest we forget entirely about the speed issue and focus instead on getting to some solutions. For example, instead of stubbornly denying that Set literals aren't as important as List literals, can you, as an avid set user, shed some light on how acceptable some of the alternative proposals are, such as: [1, 2, 3].toSet(); new Set[1, 2, 3]; //keep in mind that without the 'new', this syntax is pretty much impossible to integrate into the existing java grammar, due to looking like an array dereference operation. new HashSet<>([1, 2, 3]); NB: I tested on a core2duo mac, version 1.6.0_15, and I used sets/ lists of Integer instead of String. NB2: I whole heartedly agree with Stephen Colebourne's sentiment that I don't believe adding set literals is somehow going to make java joe see the light and start using set a lot more. --Reinier Zwitserloot Like it? Tip it! http://tipit.to On 2009/30/09, at 16:02, Gene Ray wrote: > Reinier-- > > I benchmarked this, and appear to have arrived at different results > than you. I used lists/sets of 10-character strings of lowercase > letters, which is close a lot of use-cases I've seen, and ran 10^7 > trials for each implementation (I used HashSet/ArrayList). For 20 > elements, set was a little over 3x faster (891 ms vs 2906 ms); for 7 > elements set was still close to twice as fast (872/1550); for 2 > elements set was still slightly faster (859/969). List was indeed > faster with only one element (906/844), but at this point, I > personally would just be using the .equals method instead. Varying > the string length (I tried 5, 20, and 50) increased or decreased > overall times slightly, but did not affect relative performance. I > would be curious to learn what you benchmarked against. > > The above was done with jdk1.6.0_12-b04, according to java -version. > > > Perfomance is not the only concern. "Sets" in java represent the > mathematical notion of a set; lists do not, and pretending that the > latter is equivalent to the former is a logical error regardless of > common practice. > > > > NB: Gene, you're trying to argue that a _literal_ set is > > going to make > > some sort of speed difference compared to a a_literal_ > > list. That > > notion is frankly ridiculous. You also lost track of the > > first rule of > > discussing speed: Test it first. So, go ahead. Benchmark a > > bunch > > of .contains() calls on a list and a set with the same > > items in it, > > both with say, 20 items in them (we are talking about > > literals, after > > all. I don't think anyone is seriously considering sticking > > hundreds > > of lines of code in a .java file to store constant data!) > > - on my own > > machine Lists are less than a factor of 2 slower. For about > > 7 items > > and down, lists are in fact faster. Also, just in case > > someone IS > > tempted to write such a large collections literal: For such > > a large > > literal, the added burden of wrapping the literal in a > > "new > > HashSet<>()" or sticking a ".toSet();" at the end > > seems trivial. > > > > I think the 'set literals are rare' seem to have it, so I > > repeat my > > plea to the set literal fans: Give us some proof they > > aren't rare. > > Given that set literals cause so much pain, the burden is > > clearly on > > the supporters of a set literal to prove why we need them. > > > > --Reinier Zwitserloot > > > > > > > > On 2009/29/09, at 21:07, Gene Ray wrote: > > > > > "Rare"? > > > > > > In my experience, Sets are not rare in well-written > > code; they're > > > only rare in code where for whatever reason the > > developer has > > > refused to use them, and instead expends effort and > > CPU time > > > iterating through an array or ArrayList to achieve the > > equivalent > > > functionality. Encouraging this sort of behavior > > further by > > > including only Lists in the new syntax is not a good > > plan. > > > > From evildeathmath at yahoo.com Thu Oct 1 07:40:56 2009 From: evildeathmath at yahoo.com (Gene Ray) Date: Thu, 1 Oct 2009 07:40:56 -0700 (PDT) Subject: list literal gotcha and suggestion In-Reply-To: <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> Message-ID: <317798.50308.qm@web112319.mail.gq1.yahoo.com> --- On Thu, 10/1/09, Reinier Zwitserloot wrote: > From: Reinier Zwitserloot > Subject: Re: list literal gotcha and suggestion > To: "Gene Ray" > Cc: coin-dev at openjdk.java.net > Date: Thursday, October 1, 2009, 1:25 PM > How is a mere constant factor of 3 > relevant when the set/list contains so few entries? Writing > code with performance in mind before you actually run into a > performance problem is bad, but designing the language with > this in mind is undoubtedly worse. Given that the performance characteristics of the data structures are well-understood and have been for decades, I fail to see how taking them into account when designing a language feature is premature. As an analogy, if you were in the position several years ago of writing Collections.sort()/Arrays.sort() for the first time, would you suggest using an O(n^2) sort algorithm such as bubble sort instead of an O(n log n) merge-sort or quicksort when writing a new library simply because the as-yet-unwritten library hadn't yet experienced performance issues? > For example, instead of stubbornly denying that > Set literals aren't as important as List literals, can > you, as an avid set user, shed some light on how acceptable > some of the alternative proposals are, such as: > [1, 2, 3].toSet(); > new Set[1, 2, 3]; //keep in mind that without > the 'new', this syntax is pretty much impossible to > integrate into the existing java grammar, due to looking > like an array dereference operation. > new HashSet<>([1, 2, 3]); Considering that the main point of introducting collection literals of any kind would be to reduce perceived boilerplate, I see minimal value in implementing Set literals in a fashion that is by definition tacking additional boilerplate onto the List syntax. > > NB: I tested on a core2duo mac, version > 1.6.0_15, and I used sets/lists of Integer instead of > String. Which implementation of set/list did you use? w/ArrayList and HashSet of Integer, I find the point of equal-performance to be somewhere between 2 and 3 elements on a Core2Duo WinXP machine. > NB2: I whole heartedly agree with Stephen > Colebourne's sentiment that I don't believe adding > set literals is somehow going to make java joe see the light > and start using set a lot more. I unfortunately suspect that this assessment is correct. I disagree that it is a reason to cater solely to the hypothetical "Java Joe" point of view when attempting to evolve the language. Currently, with Set and List both being aspects of a core library with equivalent syntax, they are on equal footing; introducing a new inconsistency to the basic syntax where none now exists without a strongly compelling reason to do so is dubious, and adding one very specific change while deliberately leaving other parallel changes out in order to appeal to what the broadest-base of programmers might find convenient now is (to blatant purloin a phrase from one of Neal Gafter's posts) "a lack of consideration for the long-term evolution of the language." From jjb at google.com Thu Oct 1 07:44:21 2009 From: jjb at google.com (Joshua Bloch) Date: Thu, 1 Oct 2009 07:44:21 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <17b2302a0910010744m3a903166q4d0aa2d28e2177d@mail.gmail.com> Paul, Of course you can do it with static methods and varargs, but it won't be as pretty. That's the whole idea of syntactic sugar: make common patterns easy to read and write. Josh On Wed, Sep 30, 2009 at 12:24 PM, Paul Benedict wrote: > Stephen, > > My apologies for not seeing that you already responded with a similar > suggestion. I am glad to know that you and others are not alone in > wanting static methods. > > PS: To those managing the Java language, please let's try to avoid > having two ways of doing the same thing. If this proposal can be done > with static methods and varargs, I find the utility of literal > collections to be sorely diminished. > > Paul > > From pbenedict at apache.org Thu Oct 1 07:53:11 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 1 Oct 2009 09:53:11 -0500 Subject: list literal gotcha and suggestion In-Reply-To: <17b2302a0910010744m3a903166q4d0aa2d28e2177d@mail.gmail.com> References: <17b2302a0910010744m3a903166q4d0aa2d28e2177d@mail.gmail.com> Message-ID: Josh, You've been very understandable throughout this discussion; I appreciate your public willingness and candor thought. Stephen and I (and probably a few others) have raised a few "gotchas" / "puzzlers" that appear to be pretty serious with the current proposal. Will you be able to take those into consideration before anything gets cemented in stone, and perhaps share any proposed updates regarding those? Paul On Thu, Oct 1, 2009 at 9:44 AM, Joshua Bloch wrote: > Paul, > Of course you can do it with static methods and varargs, but it won't be as > pretty. ?That's the whole idea of syntactic sugar: make common patterns easy > to read and write. > ?? ? ? ? Josh > On Wed, Sep 30, 2009 at 12:24 PM, Paul Benedict > wrote: >> >> Stephen, >> >> My apologies for not seeing that you already responded with a similar >> suggestion. I am glad to know that you and others are not alone in >> wanting static methods. >> >> PS: To those managing the Java language, please let's try to avoid >> having two ways of doing the same thing. If this proposal can be done >> with static methods and varargs, I find the utility of literal >> collections to be sorely diminished. >> >> Paul >> > > From jjb at google.com Thu Oct 1 09:39:44 2009 From: jjb at google.com (Joshua Bloch) Date: Thu, 1 Oct 2009 09:39:44 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: <17b2302a0910010744m3a903166q4d0aa2d28e2177d@mail.gmail.com> Message-ID: <17b2302a0910010939y1156e8ey9bcb95aaf66de869@mail.gmail.com> Paul, Yes. But I have to work on ARM blocks first. To much to do, too little time:( Josh On Thu, Oct 1, 2009 at 7:53 AM, Paul Benedict wrote: > Josh, > > You've been very understandable throughout this discussion; I > appreciate your public willingness and candor thought. Stephen and I > (and probably a few others) have raised a few "gotchas" / "puzzlers" > that appear to be pretty serious with the current proposal. Will you > be able to take those into consideration before anything gets cemented > in stone, and perhaps share any proposed updates regarding those? > > Paul > > On Thu, Oct 1, 2009 at 9:44 AM, Joshua Bloch wrote: > > Paul, > > Of course you can do it with static methods and varargs, but it won't be > as > > pretty. That's the whole idea of syntactic sugar: make common patterns > easy > > to read and write. > > Josh > > On Wed, Sep 30, 2009 at 12:24 PM, Paul Benedict > > wrote: > >> > >> Stephen, > >> > >> My apologies for not seeing that you already responded with a similar > >> suggestion. I am glad to know that you and others are not alone in > >> wanting static methods. > >> > >> PS: To those managing the Java language, please let's try to avoid > >> having two ways of doing the same thing. If this proposal can be done > >> with static methods and varargs, I find the utility of literal > >> collections to be sorely diminished. > >> > >> Paul > >> > > > > > From evildeathmath at yahoo.com Thu Oct 1 11:18:51 2009 From: evildeathmath at yahoo.com (Gene Ray) Date: Thu, 1 Oct 2009 11:18:51 -0700 (PDT) Subject: Collection literal frequency Message-ID: <27759.95829.qm@web112303.mail.gq1.yahoo.com> Rather lacking in rigour, but perusing codebase of my current project (~200K lines), I find that I'd want to use 15 List, 17 Set, and 34 Map literals, were the option available. From mthornton at optrak.co.uk Thu Oct 1 12:05:14 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 01 Oct 2009 20:05:14 +0100 Subject: list literal gotcha and suggestion In-Reply-To: <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> Message-ID: <4AC4FD6A.2020106@optrak.co.uk> Reinier Zwitserloot wrote: > For example, instead of stubbornly denying that Set literals aren't as > important as List literals, can you, as an avid set user, shed some > light on how acceptable some of the alternative proposals are, such as: > > [1, 2, 3].toSet(); > > new Set[1, 2, 3]; //keep in mind that without the 'new', this syntax > is pretty much impossible to integrate into the existing java grammar, > due to looking like an array dereference operation. > > new HashSet<>([1, 2, 3]); > > There is another alternative: The value [1,2,3] should be both a List and a Set while [1, 2, 1] would be just a List. As the elements are compile time constants the compiler can easily check for duplicates. If any element appears more than once, then the result is just a List, otherwise it implements both List and Set. Regards, Mark Thornton From mthornton at optrak.co.uk Thu Oct 1 13:04:12 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 01 Oct 2009 21:04:12 +0100 Subject: list literal gotcha and suggestion In-Reply-To: <4AC4FD6A.2020106@optrak.co.uk> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> <4AC4FD6A.2020106@optrak.co.uk> Message-ID: <4AC50B3C.3080801@optrak.co.uk> Mark Thornton wrote: > Reinier Zwitserloot wrote: > >> For example, instead of stubbornly denying that Set literals aren't as >> important as List literals, can you, as an avid set user, shed some >> light on how acceptable some of the alternative proposals are, such as: >> >> [1, 2, 3].toSet(); >> >> new Set[1, 2, 3]; //keep in mind that without the 'new', this syntax >> is pretty much impossible to integrate into the existing java grammar, >> due to looking like an array dereference operation. >> >> new HashSet<>([1, 2, 3]); >> >> >> > There is another alternative: The value [1,2,3] should be both a List > and a Set while [1, 2, 1] would be just a List. As the elements are > compile time constants the compiler can easily check for duplicates. If > any element appears more than once, then the result is just a List, > otherwise it implements both List and Set. > > > A complication with this alternative is the implementation of equals for set literals as they are also list literals: boolean equals(object o) { if (o instanceof List) return listEquality((List)o); if (o instanceof Set) return setEquality((Set)o); return false; } Where listEquality compares elements in order as specified in List.equals, and setEquality acts as specified by Set.equals. Regards, Mark Thornton From tim at peierls.net Thu Oct 1 13:05:26 2009 From: tim at peierls.net (Tim Peierls) Date: Thu, 1 Oct 2009 16:05:26 -0400 Subject: list literal gotcha and suggestion In-Reply-To: <4AC4FD6A.2020106@optrak.co.uk> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> <4AC4FD6A.2020106@optrak.co.uk> Message-ID: <63b4e4050910011305r517ddc48odfc05f4f168d5e00@mail.gmail.com> That would make for an awfully exciting type system. Paris in the the spring. Quick, sentence or not? --tim On Thu, Oct 1, 2009 at 3:05 PM, Mark Thornton wrote: > There is another alternative: The value [1,2,3] should be both a List > and a Set while [1, 2, 1] would be just a List. As the elements are > compile time constants the compiler can easily check for duplicates. If > any element appears more than once, then the result is just a List, > otherwise it implements both List and Set. > From mthornton at optrak.co.uk Thu Oct 1 13:21:20 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 01 Oct 2009 21:21:20 +0100 Subject: list literal gotcha and suggestion In-Reply-To: <4ac50df9.9413f30a.4c9c.169c@mx.google.com> References: <4ac50df9.9413f30a.4c9c.169c@mx.google.com> Message-ID: <4AC50F40.8080000@optrak.co.uk> Neal Gafter wrote: > I think it was intended that the expressions in these literals not be constrained to be constants. > > I did read the original proposal first and that does restrict them to compile time constants. Possible extension to non constant elements is also mentioned and clearly could not be done with my suggestion. Or perhaps we could just say that if any elements are not constants then the result is always a List. [1, 2, 3] implements List and Set [1, 2, 1] implements List [x] implements List [] is an empty List and Set Mark Thornton From pbenedict at apache.org Thu Oct 1 13:26:19 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 1 Oct 2009 15:26:19 -0500 Subject: list literal gotcha and suggestion Message-ID: Forgive me if this was already suggested, but assuming [] will always produce a list, couldn't the compile-time checking be enabled for a static cast? Set = (Set<>)[1, 2, 3]; // OK Set = (Set<>)[1, 2, 1]; // Error Paul From Kai.Kunstmann at combase.de Thu Oct 1 12:21:59 2009 From: Kai.Kunstmann at combase.de (Kai Kunstmann) Date: Thu, 01 Oct 2009 21:21:59 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20909301302s584de29fm875bead2e853ee94@mail.gmail.com> References: <17b2302a0909282234g76793a10s4410e3bd9b6d38b7@mail.gmail.com> <4AC1BA4E.5040108@optrak.co.uk> <05B24737-9714-4078-87BD-87D36952E5EF@zwitserloot.com> <4AC1BF0B.9000109@optrak.co.uk> <0828DA51-FD90-44C3-925A-A2AA3F196308@zwitserloot.com> <4b4f45e00909290253n6233da74we0c900a23b6a4003@mail.gmail.com> <4AC3A409.7090905@sun.com> <15e8b9d20909301302s584de29fm875bead2e853ee94@mail.gmail.com> Message-ID: <1254424919.953.435.camel@box.cag.combase.de> Hey y'all I've been following this discussion and the overall process of the coin-project (unfortunatelly, only since a little after the proposal periode). I'm just an ordinary developer who will eventually be using the new features you guys are going to introduce to the Java language. So far, I'm not too happy about it, which is why I'm sending this mail. I support Mr. Gafter's opinion about the "lack of consideration for the long-term evolution of the language", which is why I'm also very concerned about the results of the coin proposals to be of beneficial value (with all due respect). About this particular issue: I reeeaaaally don't like the idea of a language literal such as the proposed one to actually be some kind of implementation of some interface, especially out of the java.util.* package. Notice something? Yes, this is literals extending classes, which is anything but syntactic sugar (as opposed to literals building on top of interfaces, as with the enhanced for-each loop). Having this said, I realize the proposal breaks one basic rule: Objects are created by the "new" operator. The breaking of this rule is the true reason, why auto-boxing bugs everyone. Don't repeat mistakes! The strongest argument against this proposal is, however, that we don't need an additional extra-special-super-plus syntax for something that could be accomplished with no more than an ordinary factory method, which would suit just fine in the java.util.* package (quote someone). Iff any kind of "collection" literal, I would prefer struct-like multi-type tuples similar to (one-type) arrays. A tuple would be something like (but not the same as) a variable-generic-type Object array with the generic-types bound to the corresponding indices for type inference. Such tuples could then be used, e.g. for multiple return values and as arguments to a static Map factory. Suppose something like this: public static HashMap of([] ... tuples) { HashMap map = new HashMap(); for ([] tuple : tuples) map.put(tuple[0], tuple[1]); // type inference by index return map; } used like that: HashMap map = HashMap.of({ 1, "one" }, { 2, "two" }); // or maybe ... HashMap.of([ 1, "one" ], [ 2, "two" ]); // or even ... HashMap.of(( 1, "one" ), ( 2, "two" )); // ...so that "{..}" may be used for future closures which is short for something like this: HashMap map = HashMap.of( new []{ 1, "one" }, new []{ 2, "two" }); ( Yes, I just broke the creation-by-new-operator rule, but I promise it's barely an Object! ) Now, this is way too late and way too much for the coin-project, and it will most certainly break something in the type-system anyway, so don't consider it a proposal but just my two cents. My basic message is the first few paragraphs: Don't have literals inherit from classes! Don't have special purpose construction syntax! Object's are created by the "new" operator! Vote for Republicans! Kai Kunstmann Am Mittwoch, den 30.09.2009, 13:02 -0700 schrieb Neal Gafter: > On Wed, Sep 30, 2009 at 11:31 AM, Jonathan Gibbons > wrote: > > > +1 for the suggestion regarding HashSet.of, ArrayList.of, etc. > > > > This whole discussion over which type of brackets to use for which > > literal illustrates well why Java Is Not C. Java's design point is to > > go for clarity over obscurity at the cost of typing a few more > > characters. The fact that there can be such an ongoing discussion here > > illustrates why these literals are such a bad idea, when there are such > > clear and relatively simple alternatives. > > > > That all being said, I think map literals *are* a good idea, just > > because there is no reasonable alternative that can be used today. And > > even then, you really only need a syntax for a "pair", as in Expression > > ":" Expression. If you had that construct, then you could easily write > > HashMap.of(1: "1", 2: "2"), or TreeMap.of(1: "1", 2: "2"), etc > > > > I agree that a solution along these lines is a better approach for these > literals. However, I don't think the binary ":" operator is the best way to > introduce a pair literal. Besides the ambiguity in the second position of a > ?: expression (which can be resolved by precedence), this conflicts with the > most likely syntax for named parameters*. > > This is an example of an ongoing problem with the Coin design process. > There seems to be a lack of consideration for the long-term evolution of the > language. Many of the Coin proposals (including accepted ones) conflict > with reasonable (and likely and worthwhile) future directions. In other > words, they may be local improvements in the language design space, but they > are not always working toward global maxima. > > Cheers, > Neal > > * Incidentally, I take issue with parts of Alex Buckley's analysis of the > design space for named > parameters. > He sets up some strawman designs and then shows how they fail to support > named parameters with reordering. We added support for named parameters in > version 4.0 of the C# language, including support for reordering, and our > experience is that the change is quite beneficial. Alex's analysis > demonstrates that the design space requires more exploration before > committing to a particular design for Java. > From mthornton at optrak.co.uk Thu Oct 1 13:46:19 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 01 Oct 2009 21:46:19 +0100 Subject: list literal gotcha and suggestion In-Reply-To: <63b4e4050910011305r517ddc48odfc05f4f168d5e00@mail.gmail.com> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> <4AC4FD6A.2020106@optrak.co.uk> <63b4e4050910011305r517ddc48odfc05f4f168d5e00@mail.gmail.com> Message-ID: <4AC5151B.1050205@optrak.co.uk> Tim Peierls wrote: > That would make for an awfully exciting type system. > > Paris in the > the spring. > > Quick, sentence or not? The The ;-) Allowing an immutable List of constants to also be a Set doesn't seem too surprising to me. In fact the original proposal might be more surprising. From the original proposal: final Set primes = { 2, 7, 31, 127, 8191, 131071, 524287 }; The order of iteration of 'primes' is undefined. With my suggestion final Set primes = [2, 7, 31, 127, 8191, 131071, 524287]; Here the iteration order is as listed because the value will also implement List. Mark Thornton From Joe.Darcy at Sun.COM Thu Oct 1 14:32:15 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 01 Oct 2009 14:32:15 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <4AC50B3C.3080801@optrak.co.uk> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> <4AC4FD6A.2020106@optrak.co.uk> <4AC50B3C.3080801@optrak.co.uk> Message-ID: <4AC51FDF.7010005@sun.com> Mark Thornton wrote: > Mark Thornton wrote: > >> Reinier Zwitserloot wrote: >> >> >>> For example, instead of stubbornly denying that Set literals aren't as >>> important as List literals, can you, as an avid set user, shed some >>> light on how acceptable some of the alternative proposals are, such as: >>> >>> [1, 2, 3].toSet(); >>> >>> new Set[1, 2, 3]; //keep in mind that without the 'new', this syntax >>> is pretty much impossible to integrate into the existing java grammar, >>> due to looking like an array dereference operation. >>> >>> new HashSet<>([1, 2, 3]); >>> >>> >>> >>> >> There is another alternative: The value [1,2,3] should be both a List >> and a Set while [1, 2, 1] would be just a List. As the elements are >> compile time constants the compiler can easily check for duplicates. If >> any element appears more than once, then the result is just a List, >> otherwise it implements both List and Set. >> >> >> >> > > A complication with this alternative is the implementation of equals for > set literals as they are also list literals: > > boolean equals(object o) { > if (o instanceof List) > return listEquality((List)o); > if (o instanceof Set) > return setEquality((Set)o); > return false; > } > > > Where listEquality compares elements in order as specified in > List.equals, and setEquality acts as specified by Set.equals. > > A class cannot simultaneously satisfy the List and Set contracts for equals; various properties fail to hold such as (a.equals(b) && a.equals(c) ==> b.equals(c)): if listset.equals(list) && listset.equals(set), list.equals(set) will *not* be true. -Joe From tim at peierls.net Thu Oct 1 14:35:43 2009 From: tim at peierls.net (Tim Peierls) Date: Thu, 1 Oct 2009 17:35:43 -0400 Subject: list literal gotcha and suggestion In-Reply-To: <4AC5151B.1050205@optrak.co.uk> References: <885297.56444.qm@web112304.mail.gq1.yahoo.com> <1991405D-B614-4C9B-9919-71224830C3F0@zwitserloot.com> <4AC4FD6A.2020106@optrak.co.uk> <63b4e4050910011305r517ddc48odfc05f4f168d5e00@mail.gmail.com> <4AC5151B.1050205@optrak.co.uk> Message-ID: <63b4e4050910011435r37cb1846wf3c1caabee8dd728@mail.gmail.com> On Thu, Oct 1, 2009 at 4:46 PM, Mark Thornton wrote: > Tim Peierls wrote: > >> That would make for an awfully exciting type system. >> >> Paris in the >> the spring. >> >> Quick, sentence or not? >> > The The ;-) > The point of that "sentence" was that it's not always easy to spot whether a sequence of values has repeats. > Allowing an immutable List of constants to also be a Set doesn't seem too > surprising to me. In fact the original proposal might be more surprising. > From the original proposal: > > final Set primes = { 2, 7, 31, 127, 8191, 131071, 524287 }; > > The order of iteration of 'primes' is undefined. With my suggestion > > final Set primes = [2, 7, 31, 127, 8191, 131071, 524287]; > > Here the iteration order is as listed because the value will also implement > List. > And I don't think that's a good idea, even if it were somehow achievable, because changing 8191 to 31, for example, would change the concrete type of primes in a way that would be difficult to track down. But I think Joe's recent message in this thread makes this all moot. --tim From abies at adres.pl Fri Oct 2 01:06:56 2009 From: abies at adres.pl (abies at adres.pl) Date: Fri, 02 Oct 2009 10:06:56 +0200 Subject: list literal gotcha and suggestion In-Reply-To: 4AC51FDF.7010005@sun.com Message-ID: "Joseph D. Darcy" napisa?(a): > A class cannot simultaneously satisfy the List and Set contracts for > equals; various properties fail to hold such as (a.equals(b) && > a.equals(c) ==> b.equals(c)): > if listset.equals(list) && listset.equals(set), list.equals(set) will > *not* be true. Even easier example is hashCode - list starts with 1 for empty and is doing *31 for each element, while set starts with 0 and is just sum of elements' hashcodes (to avoid being iteration order dependent). Regards, Artur Biesiadowski From mthornton at optrak.co.uk Fri Oct 2 01:19:19 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 02 Oct 2009 09:19:19 +0100 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <4AC5B787.4050701@optrak.co.uk> abies at adres.pl wrote: > > "Joseph D. Darcy" napisa?(a): > > > A class cannot simultaneously satisfy the List and Set contracts for > > equals; various properties fail to hold such as (a.equals(b) && > > a.equals(c) ==> b.equals(c)): > > if listset.equals(list) && listset.equals(set), list.equals(set) will > > *not* be true. > > > Even easier example is hashCode - list starts with 1 for empty and is doing *31 for each element, while set starts with 0 and is just sum of elements' hashcodes (to avoid being iteration order dependent). > > > Yes, I realised that problem after turning off my machine last night. Pity. Mark From pbenedict at apache.org Mon Oct 5 22:44:05 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 00:44:05 -0500 Subject: list literal gotcha and suggestion Message-ID: I received my latest MSDN magazine yesterday, and it brought back my memories of my (very in the past) Visual Basic days. One article displayed their latest integration with .NET collections. Here are some excerpts: Dim aList As New List(Of Integer) = { 1, 2 }; Dim aArray = { 1, 2, 3 }; Dim aMap As New Dictionary(Of Integer, String) From {{1, "Apple"}, {2, "Orange"}}; It was interesting to see a uniform initialization syntax. No need for switching symbols to indicate type. Java could do the same since { } already means initializations for array literals. Someone may want to think about why Java arrays are initialized with { } but Java lists would be initialized with [ ]. Sorry, but that isn't consistent. Here's a short summary of the good alternatives recently mailed: by Nick Parlante: List piDigits = { 3, 1, 4, 1, 5, 9, 2, 6, 5 }; Set primes = [ 2, 7, 31, 127, 8191, 131071 ]; "or if that [set literals] causes problems, just don't have a literal for sets. Lists and maps are the most common, so having a syntax for those cases is the most important." by Greg Brown: List list = ArrayList.unmodifiableList(1, 2, 3); Set set = HashSet.unmodifiableSet("a", "b", "c"); by Reinier Zwitserloot new HashSet<>(["a", "b", "c"]); List.of("a", "b", "c"); by Stephen Colebourne: Set set1 = HashSet.of("1", "2", "3"); Set set2 = {1, 2, 3}.toSet(); SortedSet set = {1, 2, 3}.toSortedSet(); MultiSet mset = {1, 2, 3}.toMultiSet(); List list1 = ArrayList.of("1", "2", "3"); List list2 = {"1", "2", "3"}; Map map1 = {1 : "1", 2 : "2", 3 : "3"}; by Neal Gafter: "I agree that a solution along these lines [map key:value pair] is a better approach for these literals. However, I don't think the binary ":" operator is the best way to introduce a pair literal. Besides the ambiguity in the second position of a ?: expression (which can be resolved by precedence), this conflicts with the most likely syntax for named parameters*." by Jonathan Gibbons: "We could also use JSR 308 annotations to achieve some amount of compile time checking of varargs argument lists." class HashSet { static HashSet of(@Unique T...) } by Florian Weimer: Map map = new HashMap() {{ put("a", 0); put("b", 1); put("c", 2); }}; by John Hendrikx: "Maps however would remain a pain to instantiate. So a good syntax for creating maps or more generally, pairs or groups of values would alleviate that. Personally I was thinking more along the lines of providing a constructor like this for Maps: public HashMap(Pair... pairs); With some new syntax to easily create Pairs: Pair p = {1: "A"}; Resulting in: new HashMap({1: "A"}, {2: "B"}, {3: "C"});" Paul From reinier at zwitserloot.com Tue Oct 6 03:11:41 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 6 Oct 2009 12:11:41 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> We went over this - target typing is asking for problems. If you can shed any light on how VB.net gets around these problems, perhaps we can reconsider it, but if not, I don't see how this changes the situation any. Some example questions that highlight why VB's system is no good: public String test() { return {{1, "Apple"}, {2, "Orange"}}.toString(); } should this return [[1, "Apple"], [2, "Orange"]] or should it return {1: "Apple", 2: "Orange"} (that is: Should it build a list of list of object and toString that, or should it build a map of Integer to String, and toString that)? public void test(Object... args) { System.out.println(args.getClass().getSimpleName()); } public void test2() { test({1, 2, 3}); } should this print: 'int[]', 'Integer[]', 'int[][]', or 'List[]'? These examples all look nice when you assign them to a properly typed variable. The moment you remove that Left-hand-side type context, these kinds of solutions tend to suck (in that it becomes a small nightmare to figure out, from a casual glance, what it is that you're looking at. List? Set? Array? Map?) I suggest that the only practical way to make target typing work is to make these literals illegal unless they are being used as the expression in a variable assignment expression or variable declaration statement. However, one of the main benefits of having literals is that you can inline a list literal with a few elements directly into a method call, which you'd obviously lose if you tack on this requirement. It helps to remember that java's method overloading makes any sort of target typing based on position in method argument list no more than a rough guestimate. --Reinier Zwitserloot On 2009/06/10, at 07:44, Paul Benedict wrote: > I received my latest MSDN magazine yesterday, and it brought back my > memories of my (very in the past) Visual Basic days. One article > displayed their latest integration with .NET collections. Here are > some excerpts: > > Dim aList As New List(Of Integer) = { 1, 2 }; > Dim aArray = { 1, 2, 3 }; > Dim aMap As New Dictionary(Of Integer, String) From {{1, "Apple"}, {2, > "Orange"}}; > > It was interesting to see a uniform initialization syntax. No need for > switching symbols to indicate type. Java could do the same since { } > already means initializations for array literals. Someone may want to > think about why Java arrays are initialized with { } but Java lists > would be initialized with [ ]. Sorry, but that isn't consistent. > > Here's a short summary of the good alternatives recently mailed: > > by Nick Parlante: > List piDigits = { 3, 1, 4, 1, 5, 9, 2, 6, 5 }; > Set primes = [ 2, 7, 31, 127, 8191, 131071 ]; > "or if that [set literals] causes problems, just don't have a literal > for sets. Lists and maps are the most common, so having a syntax for > those cases is the most important." > > by Greg Brown: > List list = ArrayList.unmodifiableList(1, 2, 3); > Set set = HashSet.unmodifiableSet("a", "b", "c"); > > by Reinier Zwitserloot > new HashSet<>(["a", "b", "c"]); > List.of("a", "b", "c"); > > by Stephen Colebourne: > Set set1 = HashSet.of("1", "2", "3"); > Set set2 = {1, 2, 3}.toSet(); > SortedSet set = {1, 2, 3}.toSortedSet(); > MultiSet mset = {1, 2, 3}.toMultiSet(); > List list1 = ArrayList.of("1", "2", "3"); > List list2 = {"1", "2", "3"}; > Map map1 = {1 : "1", 2 : "2", 3 : "3"}; > > by Neal Gafter: > "I agree that a solution along these lines [map key:value pair] is a > better approach for these literals. However, I don't think the binary > ":" operator is the best way to > introduce a pair literal. Besides the ambiguity in the second > position of a ?: expression (which can be resolved by precedence), > this conflicts with the most likely syntax for named parameters*." > > by Jonathan Gibbons: > "We could also use JSR 308 annotations to achieve some amount of > compile time checking of varargs argument lists." > class HashSet { > static HashSet of(@Unique T...) > } > > by Florian Weimer: > Map map = new HashMap() {{ > put("a", 0); > put("b", 1); > put("c", 2); > }}; > > by John Hendrikx: > "Maps however would remain a pain to instantiate. So a good syntax > for creating maps or more generally, pairs or groups of values would > alleviate that. Personally I was thinking more along the lines of > providing a constructor like this for Maps: > public HashMap(Pair... pairs); > With some new syntax to easily create Pairs: > Pair p = {1: "A"}; > Resulting in: > new HashMap({1: "A"}, {2: "B"}, {3: "C"});" > > Paul > From mthornton at optrak.co.uk Tue Oct 6 03:18:19 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Tue, 06 Oct 2009 11:18:19 +0100 Subject: list literal gotcha and suggestion In-Reply-To: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> References: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> Message-ID: <4ACB196B.4090508@optrak.co.uk> Reinier Zwitserloot wrote: > > These examples all look nice when you assign them to a properly typed > variable. The moment you remove that Left-hand-side type context, > these kinds of solutions tend to suck (in that it becomes a small > nightmare to figure out, from a casual glance, what it is that you're > looking at. List? Set? Array? Map?) I suggest that the only practical > way to make target typing work is to make these literals illegal > unless they are being used as the expression in a variable assignment > expression or variable declaration statement. However, one of the main > benefits of having literals is that you can inline a list literal with > a few elements directly into a method call, which you'd obviously lose > if you tack on this requirement. It helps to remember that java's > method overloading makes any sort of target typing based on position > in method argument list no more than a rough guestimate. > > Would it be possible to allow it when the target type is unambiguous? Mark Thornton From neal at gafter.com Tue Oct 6 07:45:54 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 07:45:54 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> References: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> Message-ID: <15e8b9d20910060745p1f1790d4xf043f5e7eadd6b58@mail.gmail.com> The same effect can be had without target typing. Essentially, one defines the {}-literals in terms of a newly introduced type/class, and then define compile-time conversions from that new type to each of the types you want it to convert to. Java's type inference, for example (including constructor type inference), can be described this way, and that's how it works inside the compiler. On Tue, Oct 6, 2009 at 3:11 AM, Reinier Zwitserloot wrote: > We went over this - target typing is asking for problems. If you can > shed any light on how VB.net gets around these problems, perhaps we > can reconsider it, but if not, I don't see how this changes the > situation any. > > Some example questions that highlight why VB's system is no good: > > public String test() { > return {{1, "Apple"}, {2, "Orange"}}.toString(); > } > > should this return [[1, "Apple"], [2, "Orange"]] or should it return > {1: "Apple", 2: "Orange"} (that is: Should it build a list of list of > object and toString that, or should it build a map of Integer to > String, and toString that)? > > > public void test(Object... args) { > System.out.println(args.getClass().getSimpleName()); > } > > public void test2() { > test({1, 2, 3}); > } > > > should this print: 'int[]', 'Integer[]', 'int[][]', or 'List[]'? > > > These examples all look nice when you assign them to a properly typed > variable. The moment you remove that Left-hand-side type context, > these kinds of solutions tend to suck (in that it becomes a small > nightmare to figure out, from a casual glance, what it is that you're > looking at. List? Set? Array? Map?) I suggest that the only practical > way to make target typing work is to make these literals illegal > unless they are being used as the expression in a variable assignment > expression or variable declaration statement. However, one of the main > benefits of having literals is that you can inline a list literal with > a few elements directly into a method call, which you'd obviously lose > if you tack on this requirement. It helps to remember that java's > method overloading makes any sort of target typing based on position > in method argument list no more than a rough guestimate. > > --Reinier Zwitserloot > > > > On 2009/06/10, at 07:44, Paul Benedict wrote: > > > I received my latest MSDN magazine yesterday, and it brought back my > > memories of my (very in the past) Visual Basic days. One article > > displayed their latest integration with .NET collections. Here are > > some excerpts: > > > > Dim aList As New List(Of Integer) = { 1, 2 }; > > Dim aArray = { 1, 2, 3 }; > > Dim aMap As New Dictionary(Of Integer, String) From {{1, "Apple"}, {2, > > "Orange"}}; > > > > It was interesting to see a uniform initialization syntax. No need for > > switching symbols to indicate type. Java could do the same since { } > > already means initializations for array literals. Someone may want to > > think about why Java arrays are initialized with { } but Java lists > > would be initialized with [ ]. Sorry, but that isn't consistent. > > > > Here's a short summary of the good alternatives recently mailed: > > > > by Nick Parlante: > > List piDigits = { 3, 1, 4, 1, 5, 9, 2, 6, 5 }; > > Set primes = [ 2, 7, 31, 127, 8191, 131071 ]; > > "or if that [set literals] causes problems, just don't have a literal > > for sets. Lists and maps are the most common, so having a syntax for > > those cases is the most important." > > > > by Greg Brown: > > List list = ArrayList.unmodifiableList(1, 2, 3); > > Set set = HashSet.unmodifiableSet("a", "b", "c"); > > > > by Reinier Zwitserloot > > new HashSet<>(["a", "b", "c"]); > > List.of("a", "b", "c"); > > > > by Stephen Colebourne: > > Set set1 = HashSet.of("1", "2", "3"); > > Set set2 = {1, 2, 3}.toSet(); > > SortedSet set = {1, 2, 3}.toSortedSet(); > > MultiSet mset = {1, 2, 3}.toMultiSet(); > > List list1 = ArrayList.of("1", "2", "3"); > > List list2 = {"1", "2", "3"}; > > Map map1 = {1 : "1", 2 : "2", 3 : "3"}; > > > > by Neal Gafter: > > "I agree that a solution along these lines [map key:value pair] is a > > better approach for these literals. However, I don't think the binary > > ":" operator is the best way to > > introduce a pair literal. Besides the ambiguity in the second > > position of a ?: expression (which can be resolved by precedence), > > this conflicts with the most likely syntax for named parameters*." > > > > by Jonathan Gibbons: > > "We could also use JSR 308 annotations to achieve some amount of > > compile time checking of varargs argument lists." > > class HashSet { > > static HashSet of(@Unique T...) > > } > > > > by Florian Weimer: > > Map map = new HashMap() {{ > > put("a", 0); > > put("b", 1); > > put("c", 2); > > }}; > > > > by John Hendrikx: > > "Maps however would remain a pain to instantiate. So a good syntax > > for creating maps or more generally, pairs or groups of values would > > alleviate that. Personally I was thinking more along the lines of > > providing a constructor like this for Maps: > > public HashMap(Pair... pairs); > > With some new syntax to easily create Pairs: > > Pair p = {1: "A"}; > > Resulting in: > > new HashMap({1: "A"}, {2: "B"}, {3: "C"});" > > > > Paul > > > > > From reinier at zwitserloot.com Tue Oct 6 08:59:49 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 6 Oct 2009 17:59:49 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910060745p1f1790d4xf043f5e7eadd6b58@mail.gmail.com> References: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> <15e8b9d20910060745p1f1790d4xf043f5e7eadd6b58@mail.gmail.com> Message-ID: Which newly introduced type is flexible enough to be capable of converting it self both to a List> and to a List given: {{1, "one"}, {2, "two"}}? On 2009/06/10, at 16:45, Neal Gafter wrote: > The same effect can be had without target typing. Essentially, one > defines the {}-literals in terms of a newly introduced type/class, > and then define compile-time conversions from that new type to each > of the types you want it to convert to. Java's type inference, for > example (including constructor type inference), can be described > this way, and that's how it works inside the compiler. > > On Tue, Oct 6, 2009 at 3:11 AM, Reinier Zwitserloot > wrote: > We went over this - target typing is asking for problems. If you can > shed any light on how VB.net gets around these problems, perhaps we > can reconsider it, but if not, I don't see how this changes the > situation any. > > Some example questions that highlight why VB's system is no good: > > public String test() { > return {{1, "Apple"}, {2, "Orange"}}.toString(); > } > > should this return [[1, "Apple"], [2, "Orange"]] or should it return > {1: "Apple", 2: "Orange"} (that is: Should it build a list of list of > object and toString that, or should it build a map of Integer to > String, and toString that)? > > > public void test(Object... args) { > System.out.println(args.getClass().getSimpleName()); > } > > public void test2() { > test({1, 2, 3}); > } > > > should this print: 'int[]', 'Integer[]', 'int[][]', or 'List[]'? > > > These examples all look nice when you assign them to a properly typed > variable. The moment you remove that Left-hand-side type context, > these kinds of solutions tend to suck (in that it becomes a small > nightmare to figure out, from a casual glance, what it is that you're > looking at. List? Set? Array? Map?) I suggest that the only practical > way to make target typing work is to make these literals illegal > unless they are being used as the expression in a variable assignment > expression or variable declaration statement. However, one of the main > benefits of having literals is that you can inline a list literal with > a few elements directly into a method call, which you'd obviously lose > if you tack on this requirement. It helps to remember that java's > method overloading makes any sort of target typing based on position > in method argument list no more than a rough guestimate. > > --Reinier Zwitserloot > > > > On 2009/06/10, at 07:44, Paul Benedict wrote: > > > I received my latest MSDN magazine yesterday, and it brought back my > > memories of my (very in the past) Visual Basic days. One article > > displayed their latest integration with .NET collections. Here are > > some excerpts: > > > > Dim aList As New List(Of Integer) = { 1, 2 }; > > Dim aArray = { 1, 2, 3 }; > > Dim aMap As New Dictionary(Of Integer, String) From {{1, "Apple"}, > {2, > > "Orange"}}; > > > > It was interesting to see a uniform initialization syntax. No need > for > > switching symbols to indicate type. Java could do the same since { } > > already means initializations for array literals. Someone may want > to > > think about why Java arrays are initialized with { } but Java lists > > would be initialized with [ ]. Sorry, but that isn't consistent. > > > > Here's a short summary of the good alternatives recently mailed: > > > > by Nick Parlante: > > List piDigits = { 3, 1, 4, 1, 5, 9, 2, 6, 5 }; > > Set primes = [ 2, 7, 31, 127, 8191, 131071 ]; > > "or if that [set literals] causes problems, just don't have a > literal > > for sets. Lists and maps are the most common, so having a syntax for > > those cases is the most important." > > > > by Greg Brown: > > List list = ArrayList.unmodifiableList(1, 2, 3); > > Set set = HashSet.unmodifiableSet("a", "b", "c"); > > > > by Reinier Zwitserloot > > new HashSet<>(["a", "b", "c"]); > > List.of("a", "b", "c"); > > > > by Stephen Colebourne: > > Set set1 = HashSet.of("1", "2", "3"); > > Set set2 = {1, 2, 3}.toSet(); > > SortedSet set = {1, 2, 3}.toSortedSet(); > > MultiSet mset = {1, 2, 3}.toMultiSet(); > > List list1 = ArrayList.of("1", "2", "3"); > > List list2 = {"1", "2", "3"}; > > Map map1 = {1 : "1", 2 : "2", 3 : "3"}; > > > > by Neal Gafter: > > "I agree that a solution along these lines [map key:value pair] is a > > better approach for these literals. However, I don't think the > binary > > ":" operator is the best way to > > introduce a pair literal. Besides the ambiguity in the second > > position of a ?: expression (which can be resolved by precedence), > > this conflicts with the most likely syntax for named parameters*." > > > > by Jonathan Gibbons: > > "We could also use JSR 308 annotations to achieve some amount of > > compile time checking of varargs argument lists." > > class HashSet { > > static HashSet of(@Unique T...) > > } > > > > by Florian Weimer: > > Map map = new HashMap() {{ > > put("a", 0); > > put("b", 1); > > put("c", 2); > > }}; > > > > by John Hendrikx: > > "Maps however would remain a pain to instantiate. So a good syntax > > for creating maps or more generally, pairs or groups of values would > > alleviate that. Personally I was thinking more along the lines of > > providing a constructor like this for Maps: > > public HashMap(Pair... pairs); > > With some new syntax to easily create Pairs: > > Pair p = {1: "A"}; > > Resulting in: > > new HashMap({1: "A"}, {2: "B"}, {3: "C"});" > > > > Paul > > > > > From pbenedict at apache.org Tue Oct 6 09:28:46 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 11:28:46 -0500 Subject: list literal gotcha and suggestion Message-ID: Reinier, >> Which newly introduced type is flexible enough to be capable of >> converting it self both to a List> and to a List> String> given: {{1, "one"}, {2, "two"}}? Hopefully Neal can clarify. My reading of his words was for the compiler, not the type, to have the know-how on the conversion. Did he mean a public type? I don't know. It sounds like a type internal to the compiler to re-interpret the tokens based on context. Paul From reinier at zwitserloot.com Tue Oct 6 09:45:56 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 6 Oct 2009 18:45:56 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: Nobody has yet answered my original question: What does: System.out.println({{1, "One"}, {2, "Two"}}); print? Looking at visual basic for syntax advice is not a good idea. --Reinier Zwitserloot On 2009/06/10, at 18:28, Paul Benedict wrote: > Reinier, > >>> Which newly introduced type is flexible enough to be capable of >>> converting it self both to a List> and to a >>> List>> String> given: {{1, "one"}, {2, "two"}}? > > Hopefully Neal can clarify. My reading of his words was for the > compiler, not the type, to have the know-how on the conversion. Did he > mean a public type? I don't know. It sounds like a type internal to > the compiler to re-interpret the tokens based on context. > > Paul > From pbenedict at apache.org Tue Oct 6 10:22:19 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 12:22:19 -0500 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: It's a good question. Reinier, what do you think it ought to print? I thought someone once suggested maybe literals should always be assigned a variable. The suggestion is interesting. In terms of actually using the language feature, inlining values into methods may not be a very valuable language feature. I see the inlining to be used more for reference data held in storage. Paul On Tue, Oct 6, 2009 at 11:45 AM, Reinier Zwitserloot wrote: > Nobody has yet answered my original question: > What does: > System.out.println({{1, "One"}, {2, "Two"}}); > print? Looking at visual basic for syntax advice is not a good idea. > > ?--Reinier Zwitserloot > > > On 2009/06/10, at 18:28, Paul Benedict wrote: > From neal at gafter.com Tue Oct 6 10:36:21 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 10:36:21 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: <354C2F18-C3BA-4DAE-8548-65178618004F@zwitserloot.com> <15e8b9d20910060745p1f1790d4xf043f5e7eadd6b58@mail.gmail.com> Message-ID: <15e8b9d20910061036u2c6ec825tfeec09b5c2a1a85f@mail.gmail.com> It hasn't been introduced yet. I'd call the type "an initializer list". The (compile-time) conversion rules describing what conversions are allowed and which are not allowed would be written in terms of the values of the initializers. These types need not exist at runtime, nor need there be any way of naming them in the source or declaring objects of these types. This is the approach currently used in the language to allow, for example, 3 to be assigned to a variable of type byte (even though 3 is of type int and you can't assign an int to a byte). On Tue, Oct 6, 2009 at 8:59 AM, Reinier Zwitserloot wrote: > Which newly introduced type is flexible enough to be capable of converting > it self both to a List> and to a List given: > {{1, "one"}, {2, "two"}}? > > > > On 2009/06/10, at 16:45, Neal Gafter wrote: > > The same effect can be had without target typing. Essentially, one defines > the {}-literals in terms of a newly introduced type/class, and then define > compile-time conversions from that new type to each of the types you want it > to convert to. Java's type inference, for example (including constructor > type inference), can be described this way, and that's how it works inside > the compiler. > > On Tue, Oct 6, 2009 at 3:11 AM, Reinier Zwitserloot < > reinier at zwitserloot.com> wrote: > >> We went over this - target typing is asking for problems. If you can >> shed any light on how VB.net gets around these problems, perhaps we >> can reconsider it, but if not, I don't see how this changes the >> situation any. >> >> Some example questions that highlight why VB's system is no good: >> >> public String test() { >> return {{1, "Apple"}, {2, "Orange"}}.toString(); >> } >> >> should this return [[1, "Apple"], [2, "Orange"]] or should it return >> {1: "Apple", 2: "Orange"} (that is: Should it build a list of list of >> object and toString that, or should it build a map of Integer to >> String, and toString that)? >> >> >> public void test(Object... args) { >> System.out.println(args.getClass().getSimpleName()); >> } >> >> public void test2() { >> test({1, 2, 3}); >> } >> >> >> should this print: 'int[]', 'Integer[]', 'int[][]', or 'List[]'? >> >> >> These examples all look nice when you assign them to a properly typed >> variable. The moment you remove that Left-hand-side type context, >> these kinds of solutions tend to suck (in that it becomes a small >> nightmare to figure out, from a casual glance, what it is that you're >> looking at. List? Set? Array? Map?) I suggest that the only practical >> way to make target typing work is to make these literals illegal >> unless they are being used as the expression in a variable assignment >> expression or variable declaration statement. However, one of the main >> benefits of having literals is that you can inline a list literal with >> a few elements directly into a method call, which you'd obviously lose >> if you tack on this requirement. It helps to remember that java's >> method overloading makes any sort of target typing based on position >> in method argument list no more than a rough guestimate. >> >> --Reinier Zwitserloot >> >> >> >> On 2009/06/10, at 07:44, Paul Benedict wrote: >> >> > I received my latest MSDN magazine yesterday, and it brought back my >> > memories of my (very in the past) Visual Basic days. One article >> > displayed their latest integration with .NET collections. Here are >> > some excerpts: >> > >> > Dim aList As New List(Of Integer) = { 1, 2 }; >> > Dim aArray = { 1, 2, 3 }; >> > Dim aMap As New Dictionary(Of Integer, String) From {{1, "Apple"}, {2, >> > "Orange"}}; >> > >> > It was interesting to see a uniform initialization syntax. No need for >> > switching symbols to indicate type. Java could do the same since { } >> > already means initializations for array literals. Someone may want to >> > think about why Java arrays are initialized with { } but Java lists >> > would be initialized with [ ]. Sorry, but that isn't consistent. >> > >> > Here's a short summary of the good alternatives recently mailed: >> > >> > by Nick Parlante: >> > List piDigits = { 3, 1, 4, 1, 5, 9, 2, 6, 5 }; >> > Set primes = [ 2, 7, 31, 127, 8191, 131071 ]; >> > "or if that [set literals] causes problems, just don't have a literal >> > for sets. Lists and maps are the most common, so having a syntax for >> > those cases is the most important." >> > >> > by Greg Brown: >> > List list = ArrayList.unmodifiableList(1, 2, 3); >> > Set set = HashSet.unmodifiableSet("a", "b", "c"); >> > >> > by Reinier Zwitserloot >> > new HashSet<>(["a", "b", "c"]); >> > List.of("a", "b", "c"); >> > >> > by Stephen Colebourne: >> > Set set1 = HashSet.of("1", "2", "3"); >> > Set set2 = {1, 2, 3}.toSet(); >> > SortedSet set = {1, 2, 3}.toSortedSet(); >> > MultiSet mset = {1, 2, 3}.toMultiSet(); >> > List list1 = ArrayList.of("1", "2", "3"); >> > List list2 = {"1", "2", "3"}; >> > Map map1 = {1 : "1", 2 : "2", 3 : "3"}; >> > >> > by Neal Gafter: >> > "I agree that a solution along these lines [map key:value pair] is a >> > better approach for these literals. However, I don't think the binary >> > ":" operator is the best way to >> > introduce a pair literal. Besides the ambiguity in the second >> > position of a ?: expression (which can be resolved by precedence), >> > this conflicts with the most likely syntax for named parameters*." >> > >> > by Jonathan Gibbons: >> > "We could also use JSR 308 annotations to achieve some amount of >> > compile time checking of varargs argument lists." >> > class HashSet { >> > static HashSet of(@Unique T...) >> > } >> > >> > by Florian Weimer: >> > Map map = new HashMap() {{ >> > put("a", 0); >> > put("b", 1); >> > put("c", 2); >> > }}; >> > >> > by John Hendrikx: >> > "Maps however would remain a pain to instantiate. So a good syntax >> > for creating maps or more generally, pairs or groups of values would >> > alleviate that. Personally I was thinking more along the lines of >> > providing a constructor like this for Maps: >> > public HashMap(Pair... pairs); >> > With some new syntax to easily create Pairs: >> > Pair p = {1: "A"}; >> > Resulting in: >> > new HashMap({1: "A"}, {2: "B"}, {3: "C"});" >> > >> > Paul >> > >> >> >> > > From neal at gafter.com Tue Oct 6 10:38:27 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 10:38:27 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <15e8b9d20910061038k37c189c2ua0479d4b764d2302@mail.gmail.com> On Tue, Oct 6, 2009 at 9:45 AM, Reinier Zwitserloot wrote: > Nobody has yet answered my original question: > > What does: > > System.out.println({{1, "One"}, {2, "Two"}}); > > print? Looking at visual basic for syntax advice is not a good idea. > I suggest that it be a compile-time error because the initializer isn't converted to some appropriate collection type in the source. From pbenedict at apache.org Tue Oct 6 10:42:42 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 12:42:42 -0500 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910061038k37c189c2ua0479d4b764d2302@mail.gmail.com> References: <15e8b9d20910061038k37c189c2ua0479d4b764d2302@mail.gmail.com> Message-ID: The obvious implication here is the need for a type-cast: System.out.println((List<>){{1, "One"}, {2, "Two"}}); or System.out.println((Set<>){{1, "One"}, {2, "Two"}}); or System.out.println((Map<>){{1, "One"}, {2, "Two"}}); This fits naturally with current Java expectations to resolve ambiguity. Paul On Tue, Oct 6, 2009 at 12:38 PM, Neal Gafter wrote: > On Tue, Oct 6, 2009 at 9:45 AM, Reinier Zwitserloot > wrote: >> >> Nobody has yet answered my original question: >> >> What does: >> >> System.out.println({{1, "One"}, {2, "Two"}}); >> >> print? Looking at visual basic for syntax advice is not a good idea. > > I suggest that it be a compile-time error because the initializer isn't > converted to some appropriate collection type in the source. > From pbenedict at apache.org Tue Oct 6 10:43:58 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 12:43:58 -0500 Subject: list literal gotcha and suggestion In-Reply-To: References: <15e8b9d20910061038k37c189c2ua0479d4b764d2302@mail.gmail.com> Message-ID: Some of the examples below are bogus. But the point being, that the compiler will still err when conversion is impossible -- rather implicit or explicit. On Tue, Oct 6, 2009 at 12:42 PM, Paul Benedict wrote: > The obvious implication here is the need for a type-cast: > > System.out.println((List<>){{1, "One"}, {2, "Two"}}); > or > System.out.println((Set<>){{1, "One"}, {2, "Two"}}); > or > System.out.println((Map<>){{1, "One"}, {2, "Two"}}); > > This fits naturally with current Java expectations to resolve ambiguity. > > Paul > From reinier at zwitserloot.com Tue Oct 6 12:22:04 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 6 Oct 2009 21:22:04 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> What _should_ it print? Nothing - it was a rhetorical question to show that the concept is a bad idea. The compiler should refuse to compile it because its ambiguous. I was the one who suggested that you must assign the literals to a variable. I immediately added that I thought this was a horrible plan. If you're going to assign to a variable, then there's not much point in creating the literals in the first place - if you have a variable reference, then writing a bunch of add/put calls is easy. The lack of list/map literals is so annoying precisely BECAUSE you usually need to go through declaring a variable name for it, even if your list/map is only going to be used in one place. Remember that this is all being considered just to allow set literals. We've clearly gone mad. This discussion is starting to move towards the need to cast this literal to make the target typing work. Which it really is - there's just no way short of making massive changes to java that 1 type can be autoboxed to both List> and Map - this hypothetical initializer type would need to have variable length generics in order to make it work: It would have to somehow store the notion that this is a list of lists, where each inner list matches the type tuple {Integer, String}. Is that really going to be the implementation? Seems more likely at this point that the compiler will first look at what type is actually required, and only then to start checking the structure of the initializer literals to attempt to finagle some sort of type out of it. Which is target typing. Which has been shot down before, and with good reason. The suggestion was made in order to simplify syntax. Evidently, Paul and possibly Neal seem to think that "(List<>){{1, "One"}, {2, "Two"}})" is simpler than "[[1, "One"], [2, "Two"]]". Is that really what you guys think? --Reinier Zwitserloot On 2009/06/10, at 19:22, Paul Benedict wrote: > It's a good question. Reinier, what do you think it ought to print? > > I thought someone once suggested maybe literals should always be > assigned a variable. The suggestion is interesting. In terms of > actually using the language feature, inlining values into methods may > not be a very valuable language feature. I see the inlining to be used > more for reference data held in storage. > > Paul > > On Tue, Oct 6, 2009 at 11:45 AM, Reinier Zwitserloot > wrote: >> Nobody has yet answered my original question: >> What does: >> System.out.println({{1, "One"}, {2, "Two"}}); >> print? Looking at visual basic for syntax advice is not a good idea. >> >> --Reinier Zwitserloot >> >> >> On 2009/06/10, at 18:28, Paul Benedict wrote: >> From neal at gafter.com Tue Oct 6 12:32:20 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 12:32:20 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> Message-ID: <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> On Tue, Oct 6, 2009 at 12:22 PM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > What _should_ it print? Nothing - it was a rhetorical question to show that > the concept is a bad idea. The compiler should refuse to compile it because > its ambiguous. > I was the one who suggested that you must assign the literals to a > variable. I immediately added that I thought this was a horrible plan. If > you're going to assign to a variable, then there's not much point in > creating the literals in the first place - if you have a variable reference, > then writing a bunch of add/put calls is easy. The lack of list/map literals > is so annoying precisely BECAUSE you usually need to go through declaring a > variable name for it, even if your list/map is only going to be used in one > place. Remember that this is all being considered just to allow set > literals. We've clearly gone mad. > I agree that your suggestion to require assignments is not a good one. Assignment is not necessary. The (automatic) conversion could be triggered any context that triggers the use of conversions, for example when using it as an argument to a method. This discussion is starting to move towards the need to cast this literal to > make the target typing work. > Casting isn't required either. > Which it really is - there's just no way short of making massive changes to > java that 1 type can be autoboxed to both List> and > Map - this hypothetical initializer type would need to have > variable length generics in order to make it work: It would have to somehow > store the notion that this is a list of lists, where each inner list matches > the type tuple {Integer, String}. > You seem to imagine that the type has to be denotable in java source. That is certainly NOT a requirement. > Is that really going to be the implementation? Seems more likely at this > point that the compiler will first look at what type is actually required, > and only then to start checking the structure of the initializer literals to > attempt to finagle some sort of type out of it. > Not really. The type of the initializer is "initializer with so-and-so structure". Which is either compatible with the target of the conversion or not. The suggestion was made in order to simplify syntax. Evidently, Paul and > possibly Neal seem to think that "(List<>){{1, "One"}, {2, "Two"}})" is > simpler than "[[1, "One"], [2, "Two"]]". > Not at all. I believe that the cast would be unnecessary in virtually all use contexts, just as the cast from "3" to "byte" is unnnecessary in virtually all use contexts. -Neal From pbenedict at apache.org Tue Oct 6 12:56:30 2009 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Oct 2009 14:56:30 -0500 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> Message-ID: >> The suggestion was made in order to simplify syntax. Evidently, Paul and >> possibly Neal seem to think that "(List<>){{1, "One"}, {2, "Two"}})" is >> simpler than "[[1, "One"], [2, "Two"]]". > Not at all. I believe that the cast would be unnecessary in virtually all > use contexts, just as the cast from "3" to "byte" is unnnecessary in > virtually all use contexts. Reinier, I evidently misunderstood Neal. I thought he was saying casting would still be possible if the compiler couldn't resolve it (like in the example you showed). Although Neal says casting will typically never be required, it could still be necessary for edge cases, right? In any event, I'd rather have the compiler infer everything it can whenever possible. > You seem to imagine that the type has to be denotable in java source.? That > is certainly NOT a requirement. Neal, if it is not denotable in the source, would it still appear in javax.lang.model.type ? Paul From reinier at zwitserloot.com Tue Oct 6 13:48:08 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 6 Oct 2009 22:48:08 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> Message-ID: On 2009/06/10, at 21:32, Neal Gafter wrote: > Not at all. I believe that the cast would be unnecessary in > virtually all use contexts, just as the cast from "3" to "byte" is > unnnecessary in virtually all use contexts. Doesn't coin include byte literals? I think you overstate. "Virtually all use contexts"? I'd say that methods taking in a java.util.Collection is a pretty big use context. -- Reinier Zwitserloot From neal at gafter.com Tue Oct 6 14:50:43 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 14:50:43 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> Message-ID: <15e8b9d20910061450ld093f3w2e75c1f1d269b368@mail.gmail.com> On Tue, Oct 6, 2009 at 12:56 PM, Paul Benedict wrote: > > You seem to imagine that the type has to be denotable in java source. > That > > is certainly NOT a requirement. > > Neal, if it is not denotable in the source, would it still appear in > javax.lang.model.type ? > Since you can't declare anything of these types, there is no reason for it to appear there. From neal at gafter.com Tue Oct 6 14:52:52 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 14:52:52 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> Message-ID: <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot wrote: > On 2009/06/10, at 21:32, Neal Gafter wrote: > >> Not at all. I believe that the cast would be unnecessary in virtually all >> use contexts, just as the cast from "3" to "byte" is unnnecessary in >> virtually all use contexts. >> > > Doesn't coin include byte literals? > Yes. That has nothing to do with the part of the existing language specification that allows "3" to be assigned to a "byte". I think you overstate. "Virtually all use contexts"? I'd say that methods > taking in a java.util.Collection is a pretty big use context. > Agreed, those contexts are included. -Neal From reinier at zwitserloot.com Tue Oct 6 19:45:44 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 7 Oct 2009 04:45:44 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> Message-ID: <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> So, passing a {1, 2, 3} literal inline to a method that takes a Collection will not require a cast? Please explain how that would work. --Reinier Zwitserloot On 2009/06/10, at 23:52, Neal Gafter wrote: > On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot > wrote: > On 2009/06/10, at 21:32, Neal Gafter wrote: > Not at all. I believe that the cast would be unnecessary in > virtually all use contexts, just as the cast from "3" to "byte" is > unnnecessary in virtually all use contexts. > > Doesn't coin include byte literals? > > Yes. That has nothing to do with the part of the existing language > specification that allows "3" to be assigned to a "byte". > > I think you overstate. "Virtually all use contexts"? I'd say that > methods taking in a java.util.Collection is a pretty big use context. > > Agreed, those contexts are included. > > -Neal From neal at gafter.com Tue Oct 6 22:20:15 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 6 Oct 2009 22:20:15 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> Message-ID: <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> If it is "an initializer" that is "compatible" with the "Collection" argument type, then the "conversion" exists and the method is a candidate. If the method is selected as the most specific one during overload resolution, then the generated code will "perform the conversion", which essentially means constructing the collection object. On Tue, Oct 6, 2009 at 7:45 PM, Reinier Zwitserloot wrote: > So, passing a {1, 2, 3} literal inline to a method that takes a Collection > will not require a cast? > Please explain how that would work. > > --Reinier Zwitserloot > > > > On 2009/06/10, at 23:52, Neal Gafter wrote: > > On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot < > reinier at zwitserloot.com> wrote: > >> On 2009/06/10, at 21:32, Neal Gafter wrote: >> >>> Not at all. I believe that the cast would be unnecessary in virtually >>> all use contexts, just as the cast from "3" to "byte" is unnnecessary in >>> virtually all use contexts. >>> >> >> Doesn't coin include byte literals? >> > > Yes. That has nothing to do with the part of the existing language > specification that allows "3" to be assigned to a "byte". > > I think you overstate. "Virtually all use contexts"? I'd say that methods >> taking in a java.util.Collection is a pretty big use context. >> > > Agreed, those contexts are included. > > -Neal > > > From reinier at zwitserloot.com Wed Oct 7 04:33:16 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 7 Oct 2009 13:33:16 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> Message-ID: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> You yourself said this internal type can't ever be seen in java code. Collection is an interface, so what's it going to _be_? A set? A list? A new unspecified implementation of collection that is neither? What if I pass {1, 2, 3, 1} - will the duplicate be removed? What would it toString() to? (HashSet and ArrayList have different toString() implementations). --Reinier Zwitserloot On 2009/07/10, at 07:20, Neal Gafter wrote: > If it is "an initializer" that is "compatible" with the "Collection" > argument type, then the "conversion" exists and the method is a > candidate. If the method is selected as the most specific one > during overload resolution, then the generated code will "perform > the conversion", which essentially means constructing the collection > object. > > On Tue, Oct 6, 2009 at 7:45 PM, Reinier Zwitserloot > wrote: > So, passing a {1, 2, 3} literal inline to a method that takes a > Collection will not require a cast? > > Please explain how that would work. > > --Reinier Zwitserloot > > > > On 2009/06/10, at 23:52, Neal Gafter wrote: > >> On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot > > wrote: >> On 2009/06/10, at 21:32, Neal Gafter wrote: >> Not at all. I believe that the cast would be unnecessary in >> virtually all use contexts, just as the cast from "3" to "byte" is >> unnnecessary in virtually all use contexts. >> >> Doesn't coin include byte literals? >> >> Yes. That has nothing to do with the part of the existing language >> specification that allows "3" to be assigned to a "byte". >> >> I think you overstate. "Virtually all use contexts"? I'd say that >> methods taking in a java.util.Collection is a pretty big use context. >> >> Agreed, those contexts are included. >> >> -Neal > > From forax at univ-mlv.fr Wed Oct 7 05:40:34 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 07 Oct 2009 14:40:34 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> Message-ID: <4ACC8C42.3030502@univ-mlv.fr> Reinier Zwitserloot a ?crit : > You yourself said this internal type can't ever be seen in java code. > Collection is an interface, so what's it going to _be_? A set? A list? > The compiler can also reject that code because it's ambiguous. > A new unspecified implementation of collection that is neither? What > if I pass {1, 2, 3, 1} - will the duplicate be removed? What would it > toString() to? (HashSet and ArrayList have different toString() > implementations). > > --Reinier Zwitserloot > R?mi > > > On 2009/07/10, at 07:20, Neal Gafter wrote: > > >> If it is "an initializer" that is "compatible" with the "Collection" >> argument type, then the "conversion" exists and the method is a >> candidate. If the method is selected as the most specific one >> during overload resolution, then the generated code will "perform >> the conversion", which essentially means constructing the collection >> object. >> >> On Tue, Oct 6, 2009 at 7:45 PM, Reinier Zwitserloot > >>> wrote: >>> >> So, passing a {1, 2, 3} literal inline to a method that takes a >> Collection will not require a cast? >> >> Please explain how that would work. >> >> --Reinier Zwitserloot >> >> >> >> On 2009/06/10, at 23:52, Neal Gafter wrote: >> >> >>> On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot >> >>>> wrote: >>>> >>> On 2009/06/10, at 21:32, Neal Gafter wrote: >>> Not at all. I believe that the cast would be unnecessary in >>> virtually all use contexts, just as the cast from "3" to "byte" is >>> unnnecessary in virtually all use contexts. >>> >>> Doesn't coin include byte literals? >>> >>> Yes. That has nothing to do with the part of the existing language >>> specification that allows "3" to be assigned to a "byte". >>> >>> I think you overstate. "Virtually all use contexts"? I'd say that >>> methods taking in a java.util.Collection is a pretty big use context. >>> >>> Agreed, those contexts are included. >>> >>> -Neal >>> >> > > > From reinier at zwitserloot.com Wed Oct 7 06:40:57 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 7 Oct 2009 15:40:57 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <4ACC8C42.3030502@univ-mlv.fr> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <4ACC8C42.3030502@univ-mlv.fr> Message-ID: On 2009/07/10, at 14:40, R?mi Forax wrote: > > The compiler can also reject that code because it's ambiguous. Yes - forcing you to cast it, which makes this syntax rather ugly. Neal specifically said that he included this in his "Casts are rarely neccessary" statement, but he has yet to show me how you can avoid the need for a cast in this situation. -- Reinier Zwitserloot From neal at gafter.com Wed Oct 7 08:25:12 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 7 Oct 2009 08:25:12 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> Message-ID: <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> Its type is "and initializer list with so-and-so structure". Just like the type of "3" is "integer that fits in a byte". In either case it is a type that you can't designate in the source. There would be a language requirement that an expression of one of these types must be subject to conversion to some concrete type. If you immediately toString() it, I would expect to get a compile-time error that it hasn't been converted to a concrete type. Indeed, if you really just wanted to toString() it, you could indeed cast it to some collection type. I don't imagine that need would arise very often. -Neal On Wed, Oct 7, 2009 at 4:33 AM, Reinier Zwitserloot wrote: > You yourself said this internal type can't ever be seen in java code. > Collection is an interface, so what's it going to _be_? A set? A list? A new > unspecified implementation of collection that is neither? What if I pass {1, > 2, 3, 1} - will the duplicate be removed? What would it toString() to? > (HashSet and ArrayList have different toString() implementations). > --Reinier Zwitserloot > > > > On 2009/07/10, at 07:20, Neal Gafter wrote: > > If it is "an initializer" that is "compatible" with the "Collection" > argument type, then the "conversion" exists and the method is a candidate. > If the method is selected as the most specific one during overload > resolution, then the generated code will "perform the conversion", which > essentially means constructing the collection object. > > On Tue, Oct 6, 2009 at 7:45 PM, Reinier Zwitserloot < > reinier at zwitserloot.com> wrote: > >> So, passing a {1, 2, 3} literal inline to a method that takes a Collection >> will not require a cast? >> Please explain how that would work. >> >> --Reinier Zwitserloot >> >> >> >> On 2009/06/10, at 23:52, Neal Gafter wrote: >> >> On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot < >> reinier at zwitserloot.com> wrote: >> >>> On 2009/06/10, at 21:32, Neal Gafter wrote: >>> >>>> Not at all. I believe that the cast would be unnecessary in virtually >>>> all use contexts, just as the cast from "3" to "byte" is unnnecessary in >>>> virtually all use contexts. >>>> >>> >>> Doesn't coin include byte literals? >>> >> >> Yes. That has nothing to do with the part of the existing language >> specification that allows "3" to be assigned to a "byte". >> >> I think you overstate. "Virtually all use contexts"? I'd say that methods >>> taking in a java.util.Collection is a pretty big use context. >>> >> >> Agreed, those contexts are included. >> >> -Neal >> >> >> > > From reinier at zwitserloot.com Wed Oct 7 08:55:40 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 7 Oct 2009 17:55:40 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> Message-ID: <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> So, when passing {1, 2, 3} to a method that takes 1 Collection, it will not, in fact, work without an explicit cast, then. Okay. As I said, I think that's quite a serious use case. Before you suggest that, then, the construct will default to a List - I'm not sure that's a good idea. It would be entirely the same as Stephen Colebourne's idea of having collection literals be of a to-be- created new type that has a toSet() method, except without the need to call toSet() in certain circumstances, but with the need to add a cast in others. This is piling on rules in the JLS for something that is trivially solved with a library (the toSet() method). A toMap() method would be a bad idea and wouldn't work very well with generics, but fortunately, if only list and map literals need to be made, there's no syntax issue. --Reinier Zwitserloot On 2009/07/10, at 17:25, Neal Gafter wrote: > Its type is "and initializer list with so-and-so structure". Just > like the type of "3" is "integer that fits in a byte". In either > case it is a type that you can't designate in the source. There > would be a language requirement that an expression of one of these > types must be subject to conversion to some concrete type. If you > immediately toString() it, I would expect to get a compile-time > error that it hasn't been converted to a concrete type. Indeed, if > you really just wanted to toString() it, you could indeed cast it to > some collection type. I don't imagine that need would arise very > often. > > -Neal > > On Wed, Oct 7, 2009 at 4:33 AM, Reinier Zwitserloot > wrote: > You yourself said this internal type can't ever be seen in java > code. Collection is an interface, so what's it going to _be_? A set? > A list? A new unspecified implementation of collection that is > neither? What if I pass {1, 2, 3, 1} - will the duplicate be > removed? What would it toString() to? (HashSet and ArrayList have > different toString() implementations). > > --Reinier Zwitserloot > > > > On 2009/07/10, at 07:20, Neal Gafter wrote: > >> If it is "an initializer" that is "compatible" with the >> "Collection" argument type, then the "conversion" exists and the >> method is a candidate. If the method is selected as the most >> specific one during overload resolution, then the generated code >> will "perform the conversion", which essentially means constructing >> the collection object. >> >> On Tue, Oct 6, 2009 at 7:45 PM, Reinier Zwitserloot > > wrote: >> So, passing a {1, 2, 3} literal inline to a method that takes a >> Collection will not require a cast? >> >> Please explain how that would work. >> >> --Reinier Zwitserloot >> >> >> >> On 2009/06/10, at 23:52, Neal Gafter wrote: >> >>> On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot >> > wrote: >>> On 2009/06/10, at 21:32, Neal Gafter wrote: >>> Not at all. I believe that the cast would be unnecessary in >>> virtually all use contexts, just as the cast from "3" to "byte" is >>> unnnecessary in virtually all use contexts. >>> >>> Doesn't coin include byte literals? >>> >>> Yes. That has nothing to do with the part of the existing >>> language specification that allows "3" to be assigned to a "byte". >>> >>> I think you overstate. "Virtually all use contexts"? I'd say that >>> methods taking in a java.util.Collection is a pretty big use >>> context. >>> >>> Agreed, those contexts are included. >>> >>> -Neal >> >> > > From neal at gafter.com Wed Oct 7 09:00:06 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 7 Oct 2009 09:00:06 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> Message-ID: <15e8b9d20910070900j286324a6l9d7c5c3240267bb6@mail.gmail.com> On Wed, Oct 7, 2009 at 8:55 AM, Reinier Zwitserloot wrote: > So, when passing {1, 2, 3} to a method that takes 1 Collection, it will > not, in fact, work without an explicit cast, then. Okay. As I said, I think > that's quite a serious use case. > Correction: when passing {1, 2, 3} to a method that takes 1 Collection, it will, in fact, work without a cast. Before you suggest that, then, the construct will default to a List - I'm > not sure that's a good idea > I'm suggesting that there be no such default. From reinier at zwitserloot.com Wed Oct 7 09:15:49 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 7 Oct 2009 18:15:49 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910070900j286324a6l9d7c5c3240267bb6@mail.gmail.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <15e8b9d20910070900j286324a6l9d7c5c3240267bb6@mail.gmail.com> Message-ID: Will you stop beating around the bush? What is it then? What will this code print, and will the call to test() take O(1) or O(n) time? public class Test { public void test(Collection t) { System.out.println(t.size()); System.out.println(t.contains("Hello")); } public static void main(String[] args) { test({"a", "b", "c", "a", "b", "c", /* 99,993 more strings */, "Hello"}); } } Will it take O(N) time and print '100000\ntrue\n', or will it take O(1) time and print '99997\ntrue\n'? is this legal: int x = 0; {"a", "b"}.get(x)? if it is, what new compiler magic will figure out that this literal must evidently be referring to a List, due to the get() call tacked on to it? --Reinier Zwitserloot On 2009/07/10, at 18:00, Neal Gafter wrote: > On Wed, Oct 7, 2009 at 8:55 AM, Reinier Zwitserloot > wrote: > So, when passing {1, 2, 3} to a method that takes 1 Collection, it > will not, in fact, work without an explicit cast, then. Okay. As I > said, I think that's quite a serious use case. > > Correction: when passing {1, 2, 3} to a method that takes 1 > Collection, it will, in fact, work without a cast. > > Before you suggest that, then, the construct will default to a List > - I'm not sure that's a good idea > > I'm suggesting that there be no such default. From Kai.Kunstmann at combase.de Wed Oct 7 09:19:10 2009 From: Kai.Kunstmann at combase.de (Kai Kunstmann) Date: Wed, 07 Oct 2009 18:19:10 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <4ACC8C42.3030502@univ-mlv.fr> Message-ID: <1254932350.14036.80.camel@box.cag.combase.de> Having the compiler decide on the runtime type of an object in "literal"-disguise with multiple distinct interfaces as potential results leads to serious confusion -- not to mention the effort to define the language rules for this confusion. It get's even uglier with an explicit cast as a "compile-time hint". Why not use a simple factory method in the first place (with some extra for the map-entry creation)? I really don't like the idea of literals as placeholders for implementations of selected interfaces, especially this ambiguous one-for-all way. This is supposed to be syntactic sugar! Am Mittwoch, den 07.10.2009, 15:40 +0200 schrieb Reinier Zwitserloot: > On 2009/07/10, at 14:40, R?mi Forax wrote: > > > > The compiler can also reject that code because it's ambiguous. > > > Yes - forcing you to cast it, which makes this syntax rather ugly. > Neal specifically said that he included this in his "Casts are rarely > neccessary" statement, but he has yet to show me how you can avoid the > need for a cast in this situation. > > -- Reinier Zwitserloot From per at bothner.com Wed Oct 7 09:30:41 2009 From: per at bothner.com (Per Bothner) Date: Wed, 07 Oct 2009 09:30:41 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> Message-ID: <4ACCC231.3020507@bothner.com> On 10/07/2009 08:55 AM, Reinier Zwitserloot wrote: > So, when passing {1, 2, 3} to a method that takes 1 Collection, it > will not, in fact, work without an explicit cast, then. Okay. As I > said, I think that's quite a serious use case. Frankly, I suspect it's pretty rare to use a plain "Collection", or that you'd want to pass a literal to a method that takes a Collection argument. So I don't see it as a important use case. YMMV. -- --Per Bothner per at bothner.com http://per.bothner.com/ From neal at gafter.com Wed Oct 7 10:02:08 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 7 Oct 2009 10:02:08 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <15e8b9d20910070900j286324a6l9d7c5c3240267bb6@mail.gmail.com> Message-ID: <15e8b9d20910071002m731b0026p6013fa3571c25b5a@mail.gmail.com> On Wed, Oct 7, 2009 at 9:15 AM, Reinier Zwitserloot wrote: > Will you stop beating around the bush? What is it then? > > What will this code print, and will the call to test() take O(1) or O(n) > time? > > > public class Test { > > public void test(Collection t) { > System.out.println(t.size()); > System.out.println(t.contains("Hello")); > } > > public static void main(String[] args) { > test({"a", "b", "c", "a", "b", "c", /* 99,993 more strings */, > "Hello"}); > } > } > > > Will it take O(N) time and print '100000\ntrue\n', or will it take O(1) > time and print '99997\ntrue\n'? > In practice, this will fail to compile because the size of the bytecode required to express the body of the main method doesn't fit within the JVM's limits. Ignoring that for a moment, I would expect it to take O(N) time to construct the collection, because it would be done as a sequence of operations to add one element at a time. That's the only way to reasonably extend this to non-constants (note that a collection literal itself cannot be a "compile-time constant"). It is a separate decision what kind of collection you get in this case. I suggest that it's result be some type that implements Collection but not List or Set, is immutable, and whose construction (via a factory) doesn't remove duplicates; I'd expect it to print 100000. In other words, it is the compile-time conversion from "collection literal..." to "set" that causes the duplicates to be removed, and this program doesn't trigger that conversion. I would still expect the compiler to produce warnings when it detects that a literal that is converted to a set contains duplicate values. > is this legal: > > int x = 0; > > {"a", "b"}.get(x)? > No, because the collection literal isn't subjected to a conversion to some appropriate type. Similarly, the following isn't legal: 3.getClass(); because the "3" isn't subjected to a boxing conversion. Cheers, Neal From t.salfischberger at celerity.nl Wed Oct 7 10:40:11 2009 From: t.salfischberger at celerity.nl (Tomas Salfischberger - Celerity) Date: Wed, 07 Oct 2009 19:40:11 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <4ACCC231.3020507@bothner.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> Message-ID: <4ACCD27B.6080900@celerity.nl> Hi All, I have been reading this discussion passively for 87 messages, I think we have come to the point where this will only result in a yes-vs-no type discussion without converging to a possible solution? Trying to get back to the message that started this lengthy debate on target typing, magic types and tricky situations for which proposed solutions fail: Proposed List-literal syntax is [a, b, c] and proposed Set-literal syntax is {a, b, c}. The debate started because of the possible confusion between the two. There are multiple possible solutions: - Use a single syntax for set, list and map: Seems like a lot of magic and discussion whether this is possible. Maybe proof is in the code, would it be possible to construct a proof of concept? - Drop Set-literals and use { } for lists: Lots of opposition because Sets "should be used" Following up on the second solution, would it be a plausible solution to create just a List-literal which would result in an unspecified implementation of the List-interface. Then introduce the proposed of-methods? That would take away some of the opposition to removing Set-literals as creating sets would still be possible, only with slightly more work. An example of the result: ArrayList.of({1, 2, 2, 3}); LinkedList.of({1, 2, 2, 3}); HashSet.of({1, 2, 3}); TreeSet.of({1, 2, 3}); LinkedHashSet.of({1, 2, 3}); This would also be in alignment with the statement that Sets should be used for performance reasons. When used for performance reasons I would expect the developer to consciously select the implementation with the correct characteristics and thus not use just a simple (unspecified) literal. For maps it would be possible to use the {1: "a", 2: "b", 3: "c"} syntax without confusion on what the type of that expression would be? Best regards, Tomas Salfischberger From pbenedict at apache.org Wed Oct 7 10:49:50 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 7 Oct 2009 12:49:50 -0500 Subject: What methods should go into a java.util.Objects class in JDK 7? Message-ID: Joe, Here are a few more resources that you may want to investigate for java.util.Objects: * http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html * http://static.springsource.org/spring/docs/3.0.0.M4/javadoc-api/org/springframework/util/ObjectUtils.html * http://commons.apache.org/lang/api-release/org/apache/commons/lang/ObjectUtils.html * http://hc.apache.org/httpcomponents-core/httpcore/apidocs/org/apache/http/util/LangUtils.html Paul From reinier at zwitserloot.com Wed Oct 7 12:49:18 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 7 Oct 2009 21:49:18 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <4ACCD27B.6080900@celerity.nl> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> Message-ID: <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> I've only seen serious opposition to dumping set literals from one or two voices. As far as I can remember, we were pretty solidly converging on the idea of having just map and list literals, with a toSet() method to address places where you'd rather have a set, and adding in static factory methods to HashSet and ArrayList, which would create mutables (the literals create immutables). To this date I see no problem with this approach and I haven't heard any credible major issue with it, either, other than "Sets are important". Which nobody is denying, which is where the toSet() method comes in. Am I missing something and is there any proposal to get collection literals implemented in a manner compatible with the aims of coin that is significantly better (or even at the same level as) this proposal? The major point you're missing is the proposal to make list literals implement a to-be-named concrete implementation of java.util.List that has a few useful utility methods, including at least "toSet()". The reason being that: {1, 2, 3}.toSet(); is a lot nicer than: Collections.unmodifiableSet(HashSet.of({1, 2, 3})); There was some discussion about a tiny detail - should we have of() methods that take varargs, should we have of() methods that takes a Collection (which you could then make with the list literal syntax), or should we just stick with the already existing copy constructors? As coin also includes the diamond operator this isn't as painful as in java6 - you'd have to write new HashSet<>({1, 2, 3}); if you wanted a mutable set with the first 3 positive integers in it. Then again, diamond is probably uglier than an of method. Then there's another tiny detail: Should these methods be called 'of', or 'newList'? If you're *NOT* using static imports, then 'of' is much nicer, but if you want to statically import these pseudo-constructors, 'of' is useless. --Reinier Zwitserloot On 2009/07/10, at 19:40, Tomas Salfischberger - Celerity wrote: > Hi All, > > I have been reading this discussion passively for 87 messages, I think > we have come to the point where this will only result in a yes-vs-no > type discussion without converging to a possible solution? > > Trying to get back to the message that started this lengthy debate on > target typing, magic types and tricky situations for which proposed > solutions fail: Proposed List-literal syntax is [a, b, c] and proposed > Set-literal syntax is {a, b, c}. The debate started because of the > possible confusion between the two. There are multiple possible > solutions: > > - Use a single syntax for set, list and map: Seems like a lot of magic > and discussion whether this is possible. Maybe proof is in the code, > would it be possible to construct a proof of concept? > > - Drop Set-literals and use { } for lists: Lots of opposition because > Sets "should be used" > > Following up on the second solution, would it be a plausible > solution to > create just a List-literal which would result in an unspecified > implementation of the List-interface. Then introduce the proposed > of-methods? That would take away some of the opposition to removing > Set-literals as creating sets would still be possible, only with > slightly more work. An example of the result: > > ArrayList.of({1, 2, 2, 3}); > LinkedList.of({1, 2, 2, 3}); > > HashSet.of({1, 2, 3}); > TreeSet.of({1, 2, 3}); > LinkedHashSet.of({1, 2, 3}); > > This would also be in alignment with the statement that Sets should be > used for performance reasons. When used for performance reasons I > would > expect the developer to consciously select the implementation with the > correct characteristics and thus not use just a simple (unspecified) > literal. > > For maps it would be possible to use the {1: "a", 2: "b", 3: "c"} > syntax > without confusion on what the type of that expression would be? > > Best regards, > > Tomas Salfischberger > > From lk at teamten.com Wed Oct 7 13:03:02 2009 From: lk at teamten.com (Lawrence Kesteloot) Date: Wed, 7 Oct 2009 13:03:02 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> References: <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> Message-ID: <997cab100910071303n76fe89ebh373ac4162e469dc3@mail.gmail.com> I know this is a very basic question, but what are the use cases for immutable list and map literals? I just looked through my largest Python programs and my current 80,000-line Java tree and I don't see any place where I'd use either. I occasionally need to list a bunch of stuff (e.g., lists of parameters returned by DataProviders in TestNG), but the array literal syntax works for that. Lawrence On Wed, Oct 7, 2009 at 12:49 PM, Reinier Zwitserloot wrote: > I've only seen serious opposition to dumping set literals from one or > two voices. As far as I can remember, we were pretty solidly > converging on the idea of having just map and list literals, with a > toSet() method to address places where you'd rather have a set, and > adding in static factory methods to HashSet and ArrayList, which would > create mutables (the literals create immutables). > > To this date I see no problem with this approach and I haven't heard > any credible major issue with it, either, other than "Sets are > important". Which nobody is denying, which is where the toSet() method > comes in. > > Am I missing something and is there any proposal to get collection > literals implemented in a manner compatible with the aims of coin that > is significantly better (or even at the same level as) this proposal? > > > The major point you're missing is the proposal to make list literals > implement a to-be-named concrete implementation of java.util.List that > has a few useful utility methods, including at least "toSet()". The > reason being that: > > {1, 2, 3}.toSet(); > > is a lot nicer than: > > Collections.unmodifiableSet(HashSet.of({1, 2, 3})); > > > There was some discussion about a tiny detail - should we have of() > methods that take varargs, should we have of() methods that takes a > Collection (which you could then make with the list literal syntax), > or should we just stick with the already existing copy constructors? > As coin also includes the diamond operator this isn't as painful as in > java6 - you'd have to write new HashSet<>({1, 2, 3}); if you wanted a > mutable set with the first 3 positive integers in it. Then again, > diamond is probably uglier than an of method. Then there's another > tiny detail: Should these methods be called 'of', or 'newList'? If > you're *NOT* using static imports, then 'of' is much nicer, but if you > want to statically import these pseudo-constructors, 'of' is useless. > > ?--Reinier Zwitserloot > > > On 2009/07/10, at 19:40, Tomas Salfischberger - Celerity wrote: > >> Hi All, >> >> I have been reading this discussion passively for 87 messages, I think >> we have come to the point where this will only result in a yes-vs-no >> type discussion without converging to a possible solution? >> >> Trying to get back to the message that started this lengthy debate on >> target typing, magic types and tricky situations for which proposed >> solutions fail: Proposed List-literal syntax is [a, b, c] and proposed >> Set-literal syntax is {a, b, c}. The debate started because of the >> possible confusion between the two. There are multiple possible >> solutions: >> >> - Use a single syntax for set, list and map: Seems like a lot of magic >> and discussion whether this is possible. Maybe proof is in the code, >> would it be possible to construct a proof of concept? >> >> - Drop Set-literals and use { } for lists: Lots of opposition because >> Sets "should be used" >> >> Following up on the second solution, would it be a plausible >> solution to >> create just a List-literal which would result in an unspecified >> implementation of the List-interface. Then introduce the proposed >> of-methods? That would take away some of the opposition to removing >> Set-literals as creating sets would still be possible, only with >> slightly more work. An example of the result: >> >> ArrayList.of({1, 2, 2, 3}); >> LinkedList.of({1, 2, 2, 3}); >> >> HashSet.of({1, 2, 3}); >> TreeSet.of({1, 2, 3}); >> LinkedHashSet.of({1, 2, 3}); >> >> This would also be in alignment with the statement that Sets should be >> used for performance reasons. When used for performance reasons I >> would >> expect the developer to consciously select the implementation with the >> correct characteristics and thus not use just a simple (unspecified) >> literal. >> >> For maps it would be possible to use the {1: "a", 2: "b", 3: "c"} >> syntax >> without confusion on what the type of that expression would be? >> >> Best regards, >> >> Tomas Salfischberger >> >> > > > From neal at gafter.com Wed Oct 7 13:12:04 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 7 Oct 2009 13:12:04 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> References: <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> Message-ID: <15e8b9d20910071312k695c725dh499d162fb25639ee@mail.gmail.com> On Wed, Oct 7, 2009 at 12:49 PM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > I've only seen serious opposition to dumping set literals from one or > two voices. As far as I can remember, we were pretty solidly > converging on the idea of having just map and list literals, with a > toSet() method to address places where you'd rather have a set, and > adding in static factory methods to HashSet and ArrayList, which would > create mutables (the literals create immutables). > Reinier: if you're running this JSR, it would be instructive to see your summary of the expert group's vote count on both sides of the issue, and your proposed draft spec. From t.salfischberger at celerity.nl Wed Oct 7 13:19:06 2009 From: t.salfischberger at celerity.nl (Tomas Salfischberger) Date: Wed, 07 Oct 2009 22:19:06 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> References: <5E7BCFB8-C358-41A8-AEAB-4BA05D1A877D@zwitserloot.com> <15e8b9d20910061232h794acd89r6d5ad18091988dcf@mail.gmail.com> <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> Message-ID: <4ACCF7BA.6020009@celerity.nl> Reinier Zwitserloot wrote: > The major point you're missing is the proposal to make list literals > implement a to-be-named concrete implementation of java.util.List that > has a few useful utility methods, including at least "toSet()". The > reason being that: > > {1, 2, 3}.toSet(); > > is a lot nicer than: > > Collections.unmodifiableSet(HashSet.of({1, 2, 3})); Good point, I probably skipped over it somewhere. > There was some discussion about a tiny detail - should we have of() > methods that take varargs, should we have of() methods that takes a > Collection (which you could then make with the list literal syntax), > or should we just stick with the already existing copy constructors? We would have to think about the possible use-cases we want to support: - Immutable List literal - Mutable LinkedList, HashSet etc - Immutable LinkedList, HashSet etc Possibly other combinations? > Then there's another tiny detail: Should these methods be called 'of', > or 'newList'? If you're *NOT* using static imports, then 'of' is much > nicer, but if you want to statically import these pseudo-constructors, > 'of' is useless. The 'newList' method would still cause static import conflicts with different List implementations, it would have to be' newLinkedList' which is just as much characters as 'LinkedList.of'. Thinking about tool-support I would pick the of() variant, typing "LinkedL [ctrl+space] .of" would be enough in most current IDEs to get both the import of LinkedList and the statement. The static import version would as far as I know require you to manually type the static import before using the newLinkedList() method. Tomas From pbenedict at apache.org Wed Oct 7 13:55:51 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 7 Oct 2009 15:55:51 -0500 Subject: list literal gotcha and suggestion Message-ID: Reinier, I am glad serious opposition doesn't have a time limit. The recent activity on the list indicates, at least to me, that there is growing consensus that the current proposal is inadequate. Those raising issues (definitely more than two) have made very good arguments on the limitations and pit-falls of the current syntax. Regardless, intentions are good. The discussion is driving towards enhancing and correcting -- not torpedoing -- the proposal. As things stand, these are the issues: * Should the syntax of initializing remain uniform in Java? * Are new static methods a decent enhancement regardless of this proposal? * Are collection literals immutable or mutable? * Can operations be performed on the collection literal? 3.toString() is illegal -- why would { 1, 2 }.toSet() ? Paul From reinier at zwitserloot.com Wed Oct 7 15:13:14 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 8 Oct 2009 00:13:14 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: The recent activity on this list consisted of Neal and I swapping one- liners. That doesn't really make the case for 'growing consensus of inadequacy'. You ask interesting questions, none of which have been handled in this spinoff discussion on using {} syntax for all different forms of literals, together with pseudo target typing. My answers: Q: Should the syntax of initializing remain uniform in Java? A: Obviously not; I dont think anybody is considering "new Foo[] { foo1, foo2, foo3};" to be a decent syntax for a _list_ literal. I'm guessing that's not what you meant, though. Rephrase the question? Q: are new static methods a decent enhancement regardless of this proposal? A: Yes. [Note copious use of google collections API. Also, it's obvious that Collections.unmodifiableList(Arrays.asList(item1, item2, item3)); is idiotic, and yet commonly used. Clearly something that needs fixing.] Q: Are collection literals immutable or mutable? A: Immutable. Because immutables win. Q: Can operations be performed on the collection literal? 3.toString() is illegal -- why would { 1, 2 }.toSet() ? A: Unless you propose that "FooBar".toLowerCase(); is to be made illegal, I don't really get your point here. Of course {1, 2}.toSet() should be legal. The reason "3.toString()" is not legal is because autoboxing doesn't work that way. {1, 2} is a list. It's not a vague unspecified type I'll christen a "NealCollection" which has no methods until it converts to something. Neal's point that "3" is a special integer that is assign-type compatible to a byte has no relation whatsoever to the fact that "3.toString()" doesn't work. That's an autoboxing issue. Autoboxing was a complicated but neccessary evil. Let's not introduce them to list literals where they aren't neccessary. --Reinier Zwitserloot On 2009/07/10, at 22:55, Paul Benedict wrote: > Reinier, > > I am glad serious opposition doesn't have a time limit. The recent > activity on the list indicates, at least to me, that there is growing > consensus that the current proposal is inadequate. Those raising > issues (definitely more than two) have made very good arguments on the > limitations and pit-falls of the current syntax. Regardless, > intentions are good. The discussion is driving towards enhancing and > correcting -- not torpedoing -- the proposal. > > As things stand, these are the issues: > * Should the syntax of initializing remain uniform in Java? > * Are new static methods a decent enhancement regardless of this > proposal? > * Are collection literals immutable or mutable? > * Can operations be performed on the collection literal? 3.toString() > is illegal -- why would { 1, 2 }.toSet() ? > > Paul > From markmahieu at googlemail.com Wed Oct 7 15:43:39 2009 From: markmahieu at googlemail.com (Mark Mahieu) Date: Wed, 7 Oct 2009 23:43:39 +0100 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <255620D6-161E-4CA3-AB75-30309F285DCA@googlemail.com> On 7 Oct 2009, at 23:13, Reinier Zwitserloot wrote: > Also, it's > obvious that Collections.unmodifiableList(Arrays.asList(item1, item2, > item3)); is idiotic, and yet commonly used. Clearly something that > needs fixing.] You may view that as idiotic, but it's something I'd be quite pleased to see at times - the intention (and thought process behind it) would probably have been good, even if the actual code could be improved upon. In a similar vein, if the 'average Java developer' knew the capabilities of the Collections API(s) a little better the benefits would (in my opinion) be far greater than the potential loss caused by confusing syntax etc in corner cases discussed in much of this thread. I have no crying need for collection literals personally, but pushing them in a direction which endorses one (already over-used) core collection type to the detriment of another seems pretty iffy to me. Regards, Mark From forax at univ-mlv.fr Wed Oct 7 15:58:51 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Oct 2009 00:58:51 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <4ACD1D2B.2040302@univ-mlv.fr> Le 08/10/2009 00:13, Reinier Zwitserloot a ?crit : > The recent activity on this list consisted of Neal and I swapping one- > liners. That doesn't really make the case for 'growing consensus of > inadequacy'. > > You ask interesting questions, none of which have been handled in > this spinoff discussion on using {} syntax for all different forms of > literals, together with pseudo target typing. > > My answers: > > Q: Should the syntax of initializing remain uniform in Java? > > A: Obviously not; I dont think anybody is considering "new Foo[] > { foo1, foo2, foo3};" to be a decent syntax for a _list_ literal. I'm > guessing that's not what you meant, though. Rephrase the question? > > Q: are new static methods a decent enhancement regardless of this > proposal? > > A: Yes. [Note copious use of google collections API. Also, it's > obvious that Collections.unmodifiableList(Arrays.asList(item1, item2, > item3)); is idiotic, and yet commonly used. Clearly something that > needs fixing.] > > Q: Are collection literals immutable or mutable? > > A: Immutable. Because immutables win. > > Q: Can operations be performed on the collection literal? 3.toString() > is illegal -- why would { 1, 2 }.toSet() ? > > A: Unless you propose that "FooBar".toLowerCase(); is to be made > illegal, I don't really get your point here. Of course {1, 2}.toSet() > should be legal. The reason "3.toString()" is not legal is because > autoboxing doesn't work that way. {1, 2} is a list. It's not a vague > unspecified type I'll christen a "NealCollection" which has no methods > until it converts to something. Neal's point that "3" is a special > integer that is assign-type compatible to a byte has no relation > whatsoever to the fact that "3.toString()" doesn't work. That's an > autoboxing issue. Autoboxing was a complicated but neccessary evil. > Let's not introduce them to list literals where they aren't neccessary. > To rewrite what I have understand from Neal's mails: If these lines are legals: List list = {1, 2}; Set set = {1, 2}; then {1, 2}.toString() can be illegal because {1, 2} is a an untyped collection litteral. > --Reinier Zwitserloot > R?mi > > > On 2009/07/10, at 22:55, Paul Benedict wrote: > > >> Reinier, >> >> I am glad serious opposition doesn't have a time limit. The recent >> activity on the list indicates, at least to me, that there is growing >> consensus that the current proposal is inadequate. Those raising >> issues (definitely more than two) have made very good arguments on the >> limitations and pit-falls of the current syntax. Regardless, >> intentions are good. The discussion is driving towards enhancing and >> correcting -- not torpedoing -- the proposal. >> >> As things stand, these are the issues: >> * Should the syntax of initializing remain uniform in Java? >> * Are new static methods a decent enhancement regardless of this >> proposal? >> * Are collection literals immutable or mutable? >> * Can operations be performed on the collection literal? 3.toString() >> is illegal -- why would { 1, 2 }.toSet() ? >> >> Paul >> >> > > From tim at peierls.net Wed Oct 7 15:59:01 2009 From: tim at peierls.net (Tim Peierls) Date: Wed, 7 Oct 2009 18:59:01 -0400 Subject: list literal gotcha and suggestion In-Reply-To: <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> References: <15e8b9d20910061452u2df112b2y15ac927cd04d8394@mail.gmail.com> <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> Message-ID: <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> On Wed, Oct 7, 2009 at 3:49 PM, Reinier Zwitserloot wrote: > I've only seen serious opposition to dumping set literals from one or > two voices. As far as I can remember, we were pretty solidly > converging on the idea of having just map and list literals, with a > toSet() method to address places where you'd rather have a set, and > adding in static factory methods to HashSet and ArrayList, which would > create mutables (the literals create immutables). > I would very much like to have set literals, and I still like the submitted proposal as it stands. The original post in this thread raised a valid issue, but the responses have gone a bit overboard in trying to address it. --tim From lk at teamten.com Wed Oct 7 16:02:15 2009 From: lk at teamten.com (Lawrence Kesteloot) Date: Wed, 7 Oct 2009 16:02:15 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> References: <0438AB9F-0A9F-4047-B27C-5E20742CB586@zwitserloot.com> <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> Message-ID: <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> On Wed, Oct 7, 2009 at 3:59 PM, Tim Peierls wrote: > I would very much like to have set literals Can you give me an example of how you'd use set literals? I still have yet to see a single concrete example of how someone would use list, map, or set literals in a real program. Lawrence From amalter at illegalcheese.com Wed Oct 7 16:16:31 2009 From: amalter at illegalcheese.com (Adam Malter) Date: Wed, 7 Oct 2009 19:16:31 -0400 Subject: list literal gotcha and suggestion In-Reply-To: <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> References: <15e8b9d20910062220q2605ce28s350e0062a210fa0f@mail.gmail.com> <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> Message-ID: <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> Really? http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search Seems like all sorts of configuration/static data/quick and dirty/unittest/mock/etc types of syntax would benefit. On Wed, Oct 7, 2009 at 7:02 PM, Lawrence Kesteloot wrote: > On Wed, Oct 7, 2009 at 3:59 PM, Tim Peierls wrote: >> I would very much like to have set literals > > Can you give me an example of how you'd use set literals? I still have > yet to see a single concrete example of how someone would use list, > map, or set literals in a real program. > > Lawrence > > From pbenedict at apache.org Wed Oct 7 16:50:53 2009 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 7 Oct 2009 18:50:53 -0500 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: Reinier, > Q:?Should the syntax of initializing remain uniform in Java? > A: Obviously not; I dont think anybody is considering "new Foo[] { foo1, > foo2, foo3};" to be a decent syntax for a _list_ literal. I'm guessing > that's not what you meant, though. Rephrase the question? When I say "uniform initialization syntax", I mean curly braces would continue to indicate a series of literal values. int[] a = {1, 2, 3}; List b = {1, 2, 3}; Set c = {1, 2, 3}; Map d = {{1, "apple"}, {2, "orange"}, {3, "banana"}}; As I opined before, I think one syntax is easy and naturally builds upon what is already laid down for array initialization. It to me is consistent with Java's syntactical "feel" -- while others have readily admitted PHP/Perl influence for the current proposal. > Q:?Can operations be performed on the collection literal? 3.toString()?is > illegal -- why would { 1, 2 }.toSet() ? > A: Unless you propose that "FooBar".toLowerCase(); is to be made illegal, I > don't really get your point here. I think "FooBar" is a poor example because String-literals can only be typed as Strings. If you can entertain that collection literals do not to have a type except by compiler conversion rules (as would be with a uniform initialization syntax), then refer to Neal's prior explanation on this matter. I think his explanation was adequate. Paul Paul From reinier at zwitserloot.com Wed Oct 7 17:24:21 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 8 Oct 2009 02:24:21 +0200 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <661879DA-7ACD-4A13-97AD-AB718969366B@zwitserloot.com> We covered this; in other (popular) languages, {} refers to set literals and [] refers to list literals. Either way you're going to confuse people. --Reinier Zwitserloot On 2009/08/10, at 01:50, Paul Benedict wrote: > Reinier, > >> Q: Should the syntax of initializing remain uniform in Java? >> A: Obviously not; I dont think anybody is considering "new Foo[] >> { foo1, >> foo2, foo3};" to be a decent syntax for a _list_ literal. I'm >> guessing >> that's not what you meant, though. Rephrase the question? > > When I say "uniform initialization syntax", I mean curly braces would > continue to indicate a series of literal values. > > int[] a = {1, 2, 3}; > List b = {1, 2, 3}; > Set c = {1, 2, 3}; > Map d = {{1, "apple"}, {2, "orange"}, {3, "banana"}}; > > As I opined before, I think one syntax is easy and naturally builds > upon what is already laid down for array initialization. It to me is > consistent with Java's syntactical "feel" -- while others have readily > admitted PHP/Perl influence for the current proposal. > >> Q: Can operations be performed on the collection literal? >> 3.toString() is >> illegal -- why would { 1, 2 }.toSet() ? >> A: Unless you propose that "FooBar".toLowerCase(); is to be made >> illegal, I >> don't really get your point here. > > I think "FooBar" is a poor example because String-literals can only be > typed as Strings. If you can entertain that collection literals do not > to have a type except by compiler conversion rules (as would be with a > uniform initialization syntax), then refer to Neal's prior explanation > on this matter. I think his explanation was adequate. > > Paul > > Paul From per at bothner.com Wed Oct 7 17:32:26 2009 From: per at bothner.com (Per Bothner) Date: Wed, 07 Oct 2009 17:32:26 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <661879DA-7ACD-4A13-97AD-AB718969366B@zwitserloot.com> References: <661879DA-7ACD-4A13-97AD-AB718969366B@zwitserloot.com> Message-ID: <4ACD331A.7020005@bothner.com> On 10/07/2009 05:24 PM, Reinier Zwitserloot wrote: > We covered this; in other (popular) languages, {} refers to set > literals and [] refers to list literals. > > Either way you're going to confuse people. It is more important to be internally consistent than consistent with other languages. In in Java {} is used for array-literals, which are conceptually closer to list literals. Perhaps one day arrays will (finally) implement java.util.List, which IMO argues strongly for using {} for list literals. -- --Per Bothner per at bothner.com http://per.bothner.com/ From lk at teamten.com Wed Oct 7 17:46:33 2009 From: lk at teamten.com (Lawrence Kesteloot) Date: Wed, 7 Oct 2009 17:46:33 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> References: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> Message-ID: <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> > http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search > > Seems like all sorts of configuration/static data/quick and > dirty/unittest/mock/etc types of syntax would benefit. That search returns 800 files out of a total of 11,300,000. That's one file in 14,125, or 0.007%. I would be against a feature which (1) has such an unclear correct specification; (2) provides so little advantage over a static ArrayList.of() and HashSet.of(); and (3) helps only one file in 14,125. On the other hand, the idea (proposed twice in this discussion) of have a pair literal seems much more widely useful, and would allow HashMap.of(). Lawrence From reinier at zwitserloot.com Wed Oct 7 18:33:00 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 8 Oct 2009 03:33:00 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> References: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> Message-ID: <7A7E637A-F616-448F-B77C-4E5E43EC8A93@zwitserloot.com> This isn't a fair comparison. You should obviously add any code that matches the following rough pattern: List x = new ArrayList(); x.add(expr1); x.add(expr2); Also, the very fact that list literals don't exist means people write code differently. For example, instead of writing a method that'll accept a list of foos, or accept a list of foos in a constructor, they may instead have an addFoo() method which adds them one-at-a-time to the list, even though the most likely usecase boils down to a bunch of addFoo() calls. I use ImmutableList/ImmutableMap.of() almost every day. --Reinier Zwitserloot On 2009/08/10, at 02:46, Lawrence Kesteloot wrote: >> http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of| >> ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B >> +lang:java&sbtn=Search >> >> Seems like all sorts of configuration/static data/quick and >> dirty/unittest/mock/etc types of syntax would benefit. > > That search returns 800 files out of a total of 11,300,000. That's one > file in 14,125, or 0.007%. > > I would be against a feature which (1) has such an unclear correct > specification; (2) provides so little advantage over a static > ArrayList.of() and HashSet.of(); and (3) helps only one file in > 14,125. > > On the other hand, the idea (proposed twice in this discussion) of > have a pair literal seems much more widely useful, and would allow > HashMap.of(). > > Lawrence > From lk at teamten.com Wed Oct 7 19:23:14 2009 From: lk at teamten.com (Lawrence Kesteloot) Date: Wed, 7 Oct 2009 19:23:14 -0700 Subject: list literal gotcha and suggestion In-Reply-To: <7A7E637A-F616-448F-B77C-4E5E43EC8A93@zwitserloot.com> References: <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> <7A7E637A-F616-448F-B77C-4E5E43EC8A93@zwitserloot.com> Message-ID: <997cab100910071923n5c11010dg2c11a4927198dc77@mail.gmail.com> Okay, I'll be generous and stipulate that I've underestimated it by a factor of 100. That's still only 0.7% of files in that code base. It's nowhere near, for example, foreach, which probably appears in a majority of files written since 1.5. No matter what syntax we choose for this, you can already hear the zillions of blog posts: "I can't believe they chose that ridiculous syntax for list literals. It trips me up every time I use it." Java has never been about conciseness. It has always preferred verbosity for things that are infrequent, and I count 1% of files as infrequent. Combine that with the lack of clarity in design, and you've got a solid candidate for "when in doubt, leave it out." Lawrence On Wed, Oct 7, 2009 at 6:33 PM, Reinier Zwitserloot wrote: > This isn't a fair comparison. You should obviously add any code that matches > the following rough pattern: > List x = new ArrayList(); > x.add(expr1); > x.add(expr2); > > Also, the very fact that list literals don't exist means people write code > differently. For example, instead of writing a method that'll accept a list > of foos, or accept a list of foos in a constructor, they may instead have an > addFoo() method which adds them one-at-a-time to the list, even though the > most likely usecase boils down to a bunch of addFoo() calls. > I use ImmutableList/ImmutableMap.of() almost every day. > ?--Reinier Zwitserloot > > On 2009/08/10, at 02:46, Lawrence Kesteloot wrote: > > http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search > > Seems like all sorts of configuration/static data/quick and > > dirty/unittest/mock/etc types of syntax would benefit. > > That search returns 800 files out of a total of 11,300,000. That's one > file in 14,125, or 0.007%. > > I would be against a feature which (1) has such an unclear correct > specification; (2) provides so little advantage over a static > ArrayList.of() and HashSet.of(); and (3) helps only one file in > 14,125. > > On the other hand, the idea (proposed twice in this discussion) of > have a pair literal seems much more widely useful, and would allow > HashMap.of(). > > Lawrence > > > From Kai.Kunstmann at combase.de Thu Oct 8 01:04:36 2009 From: Kai.Kunstmann at combase.de (Kai Kunstmann) Date: Thu, 08 Oct 2009 10:04:36 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> References: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> Message-ID: <1254989076.14036.105.camel@box.cag.combase.de> Am Mittwoch, den 07.10.2009, 17:46 -0700 schrieb Lawrence Kesteloot: > > http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search > > > > Seems like all sorts of configuration/static data/quick and > > dirty/unittest/mock/etc types of syntax would benefit. > > That search returns 800 files out of a total of 11,300,000. That's one > file in 14,125, or 0.007%. > > I would be against a feature which (1) has such an unclear correct > specification; (2) provides so little advantage over a static > ArrayList.of() and HashSet.of(); and (3) helps only one file in > 14,125. > > On the other hand, the idea (proposed twice in this discussion) of > have a pair literal seems much more widely useful, and would allow > HashMap.of(). A struct-like tuple literal of any arbitrary (immutable) size would cover even more use-cases, e.g. multiple return values in methods. > > Lawrence > Kai From ola.bini at gmail.com Thu Oct 8 01:09:17 2009 From: ola.bini at gmail.com (Ola Bini) Date: Thu, 08 Oct 2009 10:09:17 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <1254989076.14036.105.camel@box.cag.combase.de> References: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> <1254989076.14036.105.camel@box.cag.combase.de> Message-ID: <4ACD9E2D.20003@gmail.com> Kai Kunstmann wrote: > Am Mittwoch, den 07.10.2009, 17:46 -0700 schrieb Lawrence Kesteloot: >>> http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search >>> >>> Seems like all sorts of configuration/static data/quick and >>> dirty/unittest/mock/etc types of syntax would benefit. >> That search returns 800 files out of a total of 11,300,000. That's one >> file in 14,125, or 0.007%. >> >> I would be against a feature which (1) has such an unclear correct >> specification; (2) provides so little advantage over a static >> ArrayList.of() and HashSet.of(); and (3) helps only one file in >> 14,125. >> >> On the other hand, the idea (proposed twice in this discussion) of >> have a pair literal seems much more widely useful, and would allow >> HashMap.of(). > > > A struct-like tuple literal of any arbitrary (immutable) size would > cover even more use-cases, e.g. multiple return values in methods. Not necessarily. Tuples are generally not iteratable (Python being the exception). Also they don't actually match Collection since they have several different types. Tuples doesn't really solve any of the problems, and they would have to have different semantics than existing collections, which means larger incisions in the language. Cheers -- Ola Bini (http://olabini.com) Ioke creator (http://ioke.org) JRuby Core Developer (http://jruby.org) Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) Practical JRuby on Rails (http://apress.com/book/view/9781590598818) "Yields falsehood when quined" yields falsehood when quined. From Kai.Kunstmann at combase.de Thu Oct 8 06:21:33 2009 From: Kai.Kunstmann at combase.de (Kai Kunstmann) Date: Thu, 08 Oct 2009 15:21:33 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <4ACD9E2D.20003@gmail.com> References: <8D4EFD03-6B83-42B0-812F-24EE3F574B8B@zwitserloot.com> <15e8b9d20910070825w6d6c835dx9402b5fcf3ca261c@mail.gmail.com> <0A8A7125-68A9-49A6-AACF-3F092DD887FA@zwitserloot.com> <4ACCC231.3020507@bothner.com> <4ACCD27B.6080900@celerity.nl> <2F34A4D6-C552-4294-B356-B309C7F1A46C@zwitserloot.com> <63b4e4050910071559q3402085bv18f3205ffe5d14d7@mail.gmail.com> <997cab100910071602y2ec8e7dci5869955cc0565ab0@mail.gmail.com> <613a548a0910071616h76544427ya649de22640aef33@mail.gmail.com> <997cab100910071746t3e5e05e1g7dbe06b65397932@mail.gmail.com> <1254989076.14036.105.camel@box.cag.combase.de> <4ACD9E2D.20003@gmail.com> Message-ID: <1255008093.14036.180.camel@box.cag.combase.de> Am Donnerstag, den 08.10.2009, 10:09 +0200 schrieb Ola Bini: > Kai Kunstmann wrote: > > Am Mittwoch, den 07.10.2009, 17:46 -0700 schrieb Lawrence Kesteloot: > >>> http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search > >>> > >>> Seems like all sorts of configuration/static data/quick and > >>> dirty/unittest/mock/etc types of syntax would benefit. > >> That search returns 800 files out of a total of 11,300,000. That's one > >> file in 14,125, or 0.007%. > >> > >> I would be against a feature which (1) has such an unclear correct > >> specification; (2) provides so little advantage over a static > >> ArrayList.of() and HashSet.of(); and (3) helps only one file in > >> 14,125. > >> > >> On the other hand, the idea (proposed twice in this discussion) of > >> have a pair literal seems much more widely useful, and would allow > >> HashMap.of(). > > > > > > A struct-like tuple literal of any arbitrary (immutable) size would > > cover even more use-cases, e.g. multiple return values in methods. > > Not necessarily. Tuples are generally not iteratable (Python being the > exception). Also they don't actually match Collection since they have > several different types. Tuples doesn't really solve any of the > problems, and they would have to have different semantics than existing > collections, which means larger incisions in the language. > Tuples are not supposed to implement any kind of interface just like arrays do, and they are not a candidate for the proposed list/set/map literal. Their intent is to allow for a neat map factory method (entries are 2-element tuples). List and Set factories can already be implemented with the current language features. Tuples are to be understood as arrays of elements with different types. The type of each element/slot would be bound to the index and encoded in the generic type parameter of a tuple. Arbitrarily sized tuples would then require variable type parameters (which is not an option, I guess). The runtime-type of any tuple would simply be Object[] or an array type of the most specific type in common. public static HashMap of([] ... entries) { ... } HashMap map = HashMap.of({1, "one"}, {2, "two"}, ...); public [] getNumbers() { return { 1, 2l, BigInteger.valueOf(3l) }; } [] numbers = getNumbers(); Integer integer = numbers[0]; numbers[2] = BigInteger.valueOf(479l); for (Number number : getNumbers()) doSomethingWithNumber(number); > > Cheers From vapor1 at teleport.com Thu Oct 8 01:58:28 2009 From: vapor1 at teleport.com (Derek Foster) Date: Thu, 8 Oct 2009 04:58:28 -0400 (EDT) Subject: list literal gotcha and suggestion Message-ID: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> I've been watching this conversation fly by with interest. A few points: First of all, I do use set literals from time to time. I want there to be a convenient and reasonably concise syntax for them. Having to use an 'import' statement is not, IMHO, an acceptable option. I would vastly prefer any of these: {1, 2, 3} [1, 2, 3] {1,2,3}.toSet() to this: import java.util.Collections; Collections.unmodifiableSetOf(1, 2, 3); or this: import java.util.HashSet; HashSet.of(1, 2, 3); or even worse, this: import java.util.Collections; import java.util.HashSet; Collections.unmodifiableSet(HashSet.of(1, 2, 3)); That's just gross. Perl, Ruby and Python programmers would be laughing at us for such verbose syntax to do such a simple thing. (Well, they probably do anyway, but even more so.) Having to deal with adding import statements and long expressions involving multiple method calls just to create simple constant values of classes that are for all practical purposes built into the language seems to me to be a HUGE annoyance. The whole point of this proposal is to add syntactic sugar and make common patterns easier to use. The resulting code needs to be CONCISE. Or people simply won't use it. I hardly ever see people use "Collections.unmodifiableSet()" in the first place, just because it's too long to type (plus the hassle of importing 'Collections'), and thus most programmers I have met just don't consider the benefits of using to be worth the trouble. Overall, I like Neal's suggestion of the magic compiler type, because it leads to very simple syntax. It also has some potential for some hidden compiler magic that could also be used for some other interesting cases which have not yet been brought up in this discussion. For instance, the compiler could decide based on the context and the type of the elements, whether to convert the magic type into any of the following: class ImmutableList extends List { ... } class ImmutableSet extends Set { ... } class ImmutableMap extends Map { ... } class ImmutableCollection extends Collection { ... } T[] // Preferably, immutable using compiler magic in the same way as E.values() is for enum types class ImmutableEnumSet extends EnumSet { ... } // For enum types only, O(1) lookup class ImmutableEnumMap extends EnumMap { ... } // For enum types only, O(1) lookup class ImmutableSortedSet extends SortedSet { ... } // Optimal balanced tree constructed at compile time? class ImmutableSortedMap extends SortedMap { ... } // Optimal balanced tree constructed at compile time? Conceivably, the compiler might even be smart enough to perform more sophisticated optimizations based on the number of elements. For instance, if five or fewer elements existed, it might create a Set implementation that did a linear search over an array, and for a greater number of elements, it might use a hash-based implementation. (Of course, both of these would have to be members of the standard library.) The nice thing about all of these is that the user doesn't need to specify. The compiler can choose the most efficient implementation, while the user still gets to use a simple syntax and ignore this complexity. The possibility of conversion to an array is particularly interesting. This would mean that the following existing legal syntax: Integer[] foo = {1, 2, 3}; could be retroactively interpreted to simply be a special case of a more general syntax that would also allow uses like this: void framulate(Integer[] xValues, Integer[yValues]); framulate({1,2,3}, {4,5,6}); It also might allow forms like this to be done much more efficiently than if a collection type were used: for (Integer x : {1,2,3}} { ... } if the context of a 'foreach' loop were understood to be an array context for the purposes of these conversions. (Otherwise, I think it should be a 'Collections' context.) Another thing that I have not seen much discussion of is the limitation in the proposal that the constants used to create the literal must be compile-time constant. This seems like a severe limitation to me. I really REALLY want this limitation to go away. That is, I want this: void foo(int bar) { List x = {1, 2, 3}; // All compile-time constant initializers List y = {4, bar, 6}; // At least one initializer is not a constant for (Integer z : {7, 8, 9}) { // All compile-time constant initializers ... } } to be desugared to something like this: private static final List $INITIALIZER1 = ImmutableList.of( 1, 2, 3 ); private static final Integer[] $INITIALIZER2 = {7, 8, 9}; void foo(int bar) { List x = $INITIALIZER1; List y = ImmutableList.of(4, bar, 6); for (Integer z : $INITIALIZER2) { ... } } so that I don't have to waste the CPU's (and the garbage collector's) time creating duplicate instances of the collections which won't ever change, every time this function is executed. Note that fancier desugarings might even get the internal data structures allocated at compile time so there is no need to iterate over elements when constructing these instances: private static final Integer[] $INITIALIZER1_CONTENTS = { 1, 2, 3 }; private static final List $INITIALIZER1 = ImmutableList.withContents($INITIALIZER1_CONTENTS); void foo(int bar) { List x = $INITIALIZER1; ... } Similar tricks could be used to pre-allocate hashtables or balanced trees for Map and Set instances. Derek From hjohn at xs4all.nl Thu Oct 8 02:55:36 2009 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 08 Oct 2009 11:55:36 +0200 Subject: List, Set and Map literals Message-ID: <4ACDB718.3070800@xs4all.nl> I've been following this discussion, and I think that Java should not try and conform to what is the "standard" in other languages. Java is its own language with its roots in C style syntax. If C already has a literal syntax that is similar to what is being proposed for Java, then by all means use that. If not, then by all means use a syntax that fits well with Java, and C-style languages. Don't try and re-use syntax from other languages that donot even have C style syntax at their roots. In Java, Arrays and Lists represent the same concept. If there ever was a need for some kind of autoboxing/unboxing it would have been for Arrays and Lists. There is not a day that goes by without having to do somekind of Array or List conversion because some functions expect or return Lists and others Arrays. It is with gnashing teeth that I find myself adding extra methods in classes for returning both types, or accepting both types just to cut down on the boilerplate in caller code. Of course, I realize the autoboxing/unboxing for Arrays and Lists is a non-option. However, the reason I bring all this up is that to me, {"A", "B", "C"} means Array. And by extension, that means List. Seeing the square parenthesis syntax proposed for Lists makes me sad. It doesn't look like Java, it feels unjava. C and Java have always had a very clear distinction of the function of the various parenthesis styles. ( ) round parenthesis for casts and to customize built-in and user-defined functions [ ] square parenthesis as indexers { } curly parenthesis to define groups of related statements or literals < > angle brackets for generics The current proposal would blur the lines between the function of square and curly parenthesis. So, the way I see it, staying in the spirit of C and Java syntax, there's two good options: 1) Introduce only List and Map literals (both using curly braces), and provide static constructors for all other cases. List a = {"A", "B", "C"}; Set a = HashSet.of({"A", "B", "C"}); Map a = {1: "A", 2: "B", 3: "C"}; 2) Think of another way to differentiate Sets, that does not violate basic syntax rules. Map syntax without keys: Set a = {:"A", :"B"}; List converted to a set: Set a = {"A", "B"}.asSet(); A qualifier keyword: Set a = set {"A", "B"}; A new symbol: Set a = ${"A", "B"}; Plain old Java: Set a = new HashSet<>({"A", "B"}); --John From reinier at zwitserloot.com Thu Oct 8 10:42:12 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 8 Oct 2009 19:42:12 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> References: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> Message-ID: Derek, adding that much magic to the NealCollection means that you have to encode half of the java.util package in the JLS. It would also be extremely inflexible; any changes to the nealCollection would require JLS changes, a full backwards compatibility review, and as you add more target types, the target typing inference would become more and more complicated over time. A strange proposal from Neal "we should add closures so we can make these changes via API instead of via a language change" Gafter, indeed. This proposed complexity is all just to avoid having to type ".toSet()", or .toEnumSet(), or whatever else you need. These methods would all be plain jane API which it so much easier to add. --Reinier Zwitserloot On 2009/08/10, at 10:58, Derek Foster wrote: > I've been watching this conversation fly by with interest. A few > points: > > First of all, I do use set literals from time to time. I want there > to be a convenient and reasonably concise syntax for them. Having to > use an 'import' statement is not, IMHO, an acceptable option. I > would vastly prefer any of these: > > {1, 2, 3} > [1, 2, 3] > {1,2,3}.toSet() > > to this: > > import java.util.Collections; > Collections.unmodifiableSetOf(1, 2, 3); > > or this: > > import java.util.HashSet; > HashSet.of(1, 2, 3); > > or even worse, this: > > import java.util.Collections; > import java.util.HashSet; > Collections.unmodifiableSet(HashSet.of(1, 2, 3)); > > That's just gross. Perl, Ruby and Python programmers would be > laughing at us for such verbose syntax to do such a simple thing. > (Well, they probably do anyway, but even more so.) Having to deal > with adding import statements and long expressions involving > multiple method calls just to create simple constant values of > classes that are for all practical purposes built into the language > seems to me to be a HUGE annoyance. > > The whole point of this proposal is to add syntactic sugar and make > common patterns easier to use. The resulting code needs to be > CONCISE. Or people simply won't use it. I hardly ever see people use > "Collections.unmodifiableSet()" in the first place, just because > it's too long to type (plus the hassle of importing 'Collections'), > and thus most programmers I have met just don't consider the > benefits of using to be worth the trouble. > > Overall, I like Neal's suggestion of the magic compiler type, > because it leads to very simple syntax. It also has some potential > for some hidden compiler magic that could also be used for some > other interesting cases which have not yet been brought up in this > discussion. For instance, the compiler could decide based on the > context and the type of the elements, whether to convert the magic > type into any of the following: > > class ImmutableList extends List { ... } > class ImmutableSet extends Set { ... } > class ImmutableMap extends Map { ... } > class ImmutableCollection extends Collection { ... } > T[] // Preferably, immutable using compiler magic in the same > way as E.values() is for enum types > class ImmutableEnumSet extends EnumSet { ... } // For enum > types only, O(1) lookup > class ImmutableEnumMap extends EnumMap { ... } // For enum > types only, O(1) lookup > class ImmutableSortedSet extends SortedSet { ... } // Optimal > balanced tree constructed at compile time? > class ImmutableSortedMap extends SortedMap { ... } // Optimal > balanced tree constructed at compile time? > > Conceivably, the compiler might even be smart enough to perform more > sophisticated optimizations based on the number of elements. For > instance, if five or fewer elements existed, it might create a > Set implementation that did a linear search over an array, and > for a greater number of elements, it might use a hash-based > implementation. (Of course, both of these would have to be members > of the standard library.) > > The nice thing about all of these is that the user doesn't need to > specify. The compiler can choose the most efficient implementation, > while the user still gets to use a simple syntax and ignore this > complexity. > > The possibility of conversion to an array is particularly > interesting. This would mean that the following existing legal syntax: > > Integer[] foo = {1, 2, 3}; > > could be retroactively interpreted to simply be a special case of a > more general syntax that would also allow uses like this: > > void framulate(Integer[] xValues, Integer[yValues]); > > framulate({1,2,3}, {4,5,6}); > > It also might allow forms like this to be done much more efficiently > than if a collection type were used: > > for (Integer x : {1,2,3}} { > ... > } > > if the context of a 'foreach' loop were understood to be an array > context for the purposes of these conversions. (Otherwise, I think > it should be a 'Collections' context.) > > Another thing that I have not seen much discussion of is the > limitation in the proposal that the constants used to create the > literal must be compile-time constant. This seems like a severe > limitation to me. I really REALLY want this limitation to go away. > That is, I want this: > > void foo(int bar) { > List x = {1, 2, 3}; // All compile-time constant > initializers > List y = {4, bar, 6}; // At least one initializer is > not a constant > for (Integer z : {7, 8, 9}) { // All compile-time constant > initializers > ... > } > } > > to be desugared to something like this: > > private static final List $INITIALIZER1 = > ImmutableList.of( 1, 2, 3 ); > private static final Integer[] $INITIALIZER2 = {7, 8, 9}; > void foo(int bar) { > List x = $INITIALIZER1; > List y = ImmutableList.of(4, bar, 6); > for (Integer z : $INITIALIZER2) { > ... > } > } > > so that I don't have to waste the CPU's (and the garbage > collector's) time creating duplicate instances of the collections > which won't ever change, every time this function is executed. Note > that fancier desugarings might even get the internal data structures > allocated at compile time so there is no need to iterate over > elements when constructing these instances: > > private static final Integer[] $INITIALIZER1_CONTENTS = { 1, 2, > 3 }; > private static final List $INITIALIZER1 = > ImmutableList.withContents($INITIALIZER1_CONTENTS); > void foo(int bar) { > List x = $INITIALIZER1; > ... > } > > Similar tricks could be used to pre-allocate hashtables or balanced > trees for Map and Set instances. > > Derek > > > > > > > > > > From brucechapman at paradise.net.nz Thu Oct 8 02:31:43 2009 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Thu, 08 Oct 2009 22:31:43 +1300 Subject: list literal gotcha and suggestion In-Reply-To: References: Message-ID: <4ACDB17F.3040806@paradise.net.nz> Hi all, I have been half following this discussion, a sick family member is preventing much more. Here's a WILD IDEA that might (or more likely not ) spark someone toward a solution. I don't feel qualified to unilateral decide this won't fly. Given map syntax is { k1 : v1 , k2 : v2 } then ':' is used as the separator between the ordered elements, and ',' the separator between the unordered unique elements. Therefore following the same pattern set syntax is { A , B , C } an unordered collection of unique elements (just a Map.keySet() is a Set and list syntax is { A : B : A : C } an ordered collection allowing duplicates which leaves three ambiguities {} may be an empty set, empty list or empty map (1) {A} may be a Set or List of one element (2) {A : B} may be a map with one Map.Entry, or a list of 2 elements (3) So API gurus?... from (1) above - is it possible to create a class that complies simultaneously with Map, List and Set provided it is empty? from (2) above - is it possible to create a class that complies simultaneously with Set and List provided there is exactly one element? from (3) above is it possible to create a class the complies simultaneously with Map and List provided the Map has only a single entry, and the List has exactly two values? if we can satisfy these requirements then the syntax could be made to work, with the compiled code generating one of several objects - all immutable LiteralSet implements Set (where T is lowest common supertype of all elements) LiteralMap implements Map (where K and V are lowest common supertypes of all keys and values respectively) LiteralList implements List (where T is lowest common supertype of all elements) EmptyLiteralCollection implements List,Map,Set LiteralSingleCollection implements List, Set (where T is type of the element) LiteralSingleMapOrTwoList implements List,Map (where T is lowest common supertype of K and V) Someone please tell me why one of (1), (2) or (3) is not possible. Bruce Paul Benedict wrote: > Reinier, > > I am glad serious opposition doesn't have a time limit. The recent > activity on the list indicates, at least to me, that there is growing > consensus that the current proposal is inadequate. Those raising > issues (definitely more than two) have made very good arguments on the > limitations and pit-falls of the current syntax. Regardless, > intentions are good. The discussion is driving towards enhancing and > correcting -- not torpedoing -- the proposal. > > As things stand, these are the issues: > * Should the syntax of initializing remain uniform in Java? > * Are new static methods a decent enhancement regardless of this proposal? > * Are collection literals immutable or mutable? > * Can operations be performed on the collection literal? 3.toString() > is illegal -- why would { 1, 2 }.toSet() ? > > Paul > > > From reinier at zwitserloot.com Thu Oct 8 15:41:28 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 9 Oct 2009 00:41:28 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <15e8b9d20910081341k2c838636k958440b394a58cc0@mail.gmail.com> References: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> <15e8b9d20910081341k2c838636k958440b394a58cc0@mail.gmail.com> Message-ID: <08615089-4727-4712-8606-D4551F1B742A@zwitserloot.com> That wasn't ad hominem. Ad Hominem means: claiming a logical argument is fallacious because the person who made the argument is lacking in some regard or other. As logical arguments are independent of the person making it, such a claim is obviously itself fallacious, which is why its listed amongst the logical fallacies*. You were thus wildly off the mark, and I take offense to your insinuation that I "stooped" to anything. Furthermore, your remarks are in fact toying with the spirit of ad hominem, as they insinuate my arguments cannot be trusted simply because I'm making them. *) Possibly you meant ad hominem in the informal sense, but I don't see anything I my previous post that can even be construed as insulting your character. Another alternative is that you believe I insinuated your arguments regarding the feasibility of the {}-for-all- types syntax were somehow not right based purely on the notion that the syntax doesn't fit with your usual sentiments. I'm having a hard time reading that in my own message, but if that's the case - that's not how the comment was intended. --Reinier Zwitserloot Like it? Tip it! http://tipit.to On 2009/08/10, at 22:41, Neal Gafter wrote: > On Thu, Oct 8, 2009 at 10:42 AM, Reinier Zwitserloot > wrote: > A strange proposal from Neal "we should add closures so we can make > these changes via API instead of via a language change" Gafter, > indeed. > > Well, as long as we're stooping to ad-hominem, I should point out > that I wasn't proposing anything. You said that you don't know how > to use a single syntax for all of these collections without either > requiring casts or target typing, and concluded that it therefore > isn't possible[1]. I showed you how to do it[2], including > answering your follow-on questions. I was doing so not because I > think that is how I believe this feature should be designed[3]. Nor > because I think this feature is even worth having at all. I did so > because the participants in this list have a wide range of language- > design skills, and most probably don't realize how many of your > pronouncements are simply incorrect. > > None of this has much to do with the proposal that has already been > accepted (by Joe Darcy, not by you or me), the deliberations of its > expert group, its implementation, or the probability of it being > reviewed and checked-in to the openjdk7 "tl" workspace on schedule, > feature-complete, in the next 15 days. I don't see much risk (or > "hope" if you prefer) of that happening. > > Cheers, > Neal > October 6: (Reiner) "We went over this - target typing is asking for > problems. If you can shed any light on how VB.net gets around these > problems, perhaps we can reconsider it, but if not, I don't see how > this changes the situation any." > October 6: (Neal) "The same effect can be had without target > typing. Essentially, one defines the {}-literals in terms of a > newly introduced type/class, and then define compile-time > conversions from that new type to each of the types you want it to > convert to. Java's type inference, for example (including > constructor type inference), can be described this way, and that's > how it works inside the compiler." > Sep 30: (Neal) "I agree that a solution along these lines [API- > based] is a better approach for these literals." > From tim at peierls.net Thu Oct 8 16:49:25 2009 From: tim at peierls.net (Tim Peierls) Date: Thu, 8 Oct 2009 19:49:25 -0400 Subject: list literal gotcha and suggestion In-Reply-To: <08615089-4727-4712-8606-D4551F1B742A@zwitserloot.com> References: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> <15e8b9d20910081341k2c838636k958440b394a58cc0@mail.gmail.com> <08615089-4727-4712-8606-D4551F1B742A@zwitserloot.com> Message-ID: <63b4e4050910081649xdbdd20bk1e93666ebc967982@mail.gmail.com> On Thu, Oct 8, 2009 at 6:41 PM, Reinier Zwitserloot wrote: > *) Possibly you meant ad hominem in the informal sense, but I don't see anything I my previous post that can even be construed as > insulting your character. Sure seemed ad hominem to me, particularly the bit where you referred to Neal as 'Neal "" Gafter'. But it certainly is hard to get the tone right in these discussions. For example, to me your tone throughout this thread, Reinier "wildly off the mark" Zwitserloot, has been insulting and arrogant; I try to bear in mind that you probably don't mean it that way. --tim From neal at gafter.com Thu Oct 8 13:41:42 2009 From: neal at gafter.com (Neal Gafter) Date: Thu, 8 Oct 2009 13:41:42 -0700 Subject: list literal gotcha and suggestion In-Reply-To: References: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> Message-ID: <15e8b9d20910081341k2c838636k958440b394a58cc0@mail.gmail.com> On Thu, Oct 8, 2009 at 10:42 AM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > A strange proposal from Neal "we should add closures so we can make > these changes via API instead of via a language change" Gafter, indeed. > Well, as long as we're stooping to ad-hominem, I should point out that I wasn't proposing anything. You said that you don't know how to use a single syntax for all of these collections without either requiring casts or target typing, and concluded that it therefore isn't possible[1]. I showed you how to do it[2], including answering your follow-on questions. I was doing so not because I think that is how I believe this feature should be designed[3]. Nor because I think this feature is even worth having at all. I did so because the participants in this list have a wide range of language-design skills, and most probably don't realize how many of your pronouncements are simply incorrect. None of this has much to do with the proposal that has already been accepted (by Joe Darcy, not by you or me), the deliberations of its expert group, its implementation, or the probability of it being reviewed and checked-in to the openjdk7 "tl" workspace on schedule, *feature-complete, *in the next 15 days. I don't see much risk (or "hope" if you prefer) of that happening. Cheers, Neal 1. October 6: (Reiner) "We went over this - target typing is asking for problems. If you can shed any light on how VB.net gets around these problems, perhaps we can reconsider it, but if not, I don't see how this changes the situation any." 2. October 6: (Neal) "The same effect can be had without target typing. Essentially, one defines the {}-literals in terms of a newly introduced type/class, and then define compile-time conversions from that new type to each of the types you want it to convert to. Java's type inference, for example (including constructor type inference), can be described this way, and that's how it works inside the compiler." 3. Sep 30: (Neal) "I agree that a solution along these lines [API-based] is a better approach for these literals." From reinier at zwitserloot.com Thu Oct 8 18:06:21 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Fri, 9 Oct 2009 03:06:21 +0200 Subject: list literal gotcha and suggestion In-Reply-To: <63b4e4050910081649xdbdd20bk1e93666ebc967982@mail.gmail.com> References: <22716157.1254992308826.JavaMail.root@wamui-junio.atl.sa.earthlink.net> <15e8b9d20910081341k2c838636k958440b394a58cc0@mail.gmail.com> <08615089-4727-4712-8606-D4551F1B742A@zwitserloot.com> <63b4e4050910081649xdbdd20bk1e93666ebc967982@mail.gmail.com> Message-ID: I can quote a dozen threads where Neal suggested that moving stuff into a library is better than language changes, especially during the earlier days of coin, when closures weren't quite off the table. Check the ARM proposal thread, you'll find plenty. If you read that as an insult, perhaps you're vehemently opposed to that idea. I think I correctly characterized Neal's sentiments, and I have a hard time believing I denigrated that viewpoint, as I ascribe to it. Evidently you find the 'First name "characterization" last name' form insulting regardless of the characterization. No clue why that pushes your buttons, but now that I know I'll try to avoid it. --Reinier Zwitserloot On 2009/09/10, at 01:49, Tim Peierls wrote: > On Thu, Oct 8, 2009 at 6:41 PM, Reinier Zwitserloot > wrote: > *) Possibly you meant ad hominem in the informal sense, but I don't > see anything I my previous post that can even be construed as > insulting your character. > > Sure seemed ad hominem to me, particularly the bit where you > referred to Neal as 'Neal "" Gafter'. > > But it certainly is hard to get the tone right in these discussions. > For example, to me your tone throughout this thread, Reinier "wildly > off the mark" Zwitserloot, has been insulting and arrogant; I try to > bear in mind that you probably don't mean it that way. > > --tim From howard.lovatt at iee.org Wed Oct 21 05:15:22 2009 From: howard.lovatt at iee.org (Howard Lovatt) Date: Wed, 21 Oct 2009 14:15:22 +0200 Subject: ARM Blocks: ease of use and for loops Message-ID: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> Hi, I have been experimenting in my own code with various 'manual' versions of ARM blocks and have found the following interfaces to be useful: in package java.util; interface Closeable { void close() throws Exception; } interface CloseableIterable extends Iterable { @Override public CloseableIterator iterator(); } interface CloseableIterator extends Closeable, Iterator {} interface SafeCloseable extends java.io.Closeable { @Override void close(); } interface SafeCloseableIterable extends Iterable { @Override public SafeCloseableIterator iterator(); } interface SafeCloseableIterator extends SafeCloseable, Iterator {} in package java.io; interface Closeable extends java.util.Closeable { @Override void close() throws IOException; } The purpose of the interfaces CloseableIterable and CloseableIterator are to enable for loops to close resources automatically. A for loop whose iteratable is of type CloseableIterable, e.g.: for ( final E e : closeableIterable ) { ... } is expanded, using the new ARM block, to: try ( final CloseableIterator i = closableIterable.iterator() ) { while ( i.hasNext() ) { final E e = i.next(); ... } } The semantics of a closed iterator is that hasNext returns false and next throws a NoSuchElementException. The purpose of the Safe versions is to simplify coding in the, common in my code, cases when close doesn't throw an exception. Also note that java.io.Closeable is part of the new hierarchy for backward compatibility and also to allow SafeCloseable's to be passed in where java.io.Closeable's are expected. The ARM block only has to deal with java.util.Closeable, but the for expansion must get the types more exact (for expansion already deals with arrays and Iterables so hopefully adding CloseableIterable and SafeCloseableIterable won't be too hard). I have tried trawling the coin archives and I can't find a suggestion identical to this (though there are suggestions along these lines), so hopefully I haven't missed something in the archive and this is a new contribution. Do others think these interfaces and the for loop suggestion useful/viable? -- Howard. From neal at gafter.com Wed Oct 21 08:08:16 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 21 Oct 2009 08:08:16 -0700 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> Message-ID: <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> I definitely agree that the semantics of the foreach loop should be modified to take closability of the iterator into account, but I think it would be more in the spirit of the existing ARM proposal to do this without adding a bunch of new interfaces. For example, one approach would be: in a foreach loop over a collection expression e, if the type of e.iterator() extends Closeable, then it is automatically closed when the loop exits. On Wed, Oct 21, 2009 at 5:15 AM, Howard Lovatt wrote: > Hi, > > I have been experimenting in my own code with various 'manual' versions of > ARM blocks and have found the following interfaces to be useful: > > > in package java.util; > > interface Closeable { void close() throws Exception; } > > interface CloseableIterable extends Iterable { @Override public > CloseableIterator iterator(); } > > interface CloseableIterator extends Closeable, Iterator {} > > interface SafeCloseable extends java.io.Closeable { @Override void close(); > } > > interface SafeCloseableIterable extends Iterable { @Override public > SafeCloseableIterator iterator(); } > > interface SafeCloseableIterator extends SafeCloseable, Iterator {} > > > in package java.io; > > interface Closeable extends java.util.Closeable { @Override void close() > throws IOException; } > > > The purpose of the interfaces CloseableIterable and CloseableIterator are > to > enable for loops to close resources automatically. A for loop whose > iteratable is of type CloseableIterable, e.g.: > > for ( final E e : closeableIterable ) { ... } > > is expanded, using the new ARM block, to: > > try ( final CloseableIterator i = closableIterable.iterator() ) { > while ( i.hasNext() ) { > final E e = i.next(); > ... > } > } > > The semantics of a closed iterator is that hasNext returns false and next > throws a NoSuchElementException. The purpose of the Safe versions is to > simplify coding in the, common in my code, cases when close doesn't throw > an > exception. Also note that java.io.Closeable is part of the new hierarchy > for > backward compatibility and also to allow SafeCloseable's to be passed in > where java.io.Closeable's are expected. The ARM block only has to deal with > java.util.Closeable, but the for expansion must get the types more exact > (for expansion already deals with arrays and Iterables so hopefully adding > CloseableIterable and SafeCloseableIterable won't be too hard). > > I have tried trawling the coin archives and I can't find a suggestion > identical to this (though there are suggestions along these lines), so > hopefully I haven't missed something in the archive and this is a new > contribution. > > Do others think these interfaces and the for loop suggestion useful/viable? > > -- Howard. > > From jjb at google.com Wed Oct 21 08:39:39 2009 From: jjb at google.com (Joshua Bloch) Date: Wed, 21 Oct 2009 08:39:39 -0700 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> Message-ID: <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> I agree that this would be the right way to do it, but I'm not convinced that it meets the bar for inclusion. It's not a now-or-never thing: its and independent change to for-each. Two questions come to mind: (1) How big a win would this be in terms of expressiveness? How often (in a real code corpus) would it be applicable. How much nicer would the code corpus be with this feature. Or is it too magic? (Shorter isn't always better.) (2) Are there any dangers associated with it? Suppose an existing final class were retrofitted so that its iterator method returned a closeable iterator. Then we'd be changing the semantics of an existing for-each over that resource. Is that a problem? On balance, I'm not convinced that this is worth doing at this point. Tom Ball and I are well on our way to finishing the implementation of the basic proposal. Once we have that, we can entertain proposals for extended functionality. Regards, Josh On Wed, Oct 21, 2009 at 8:08 AM, Neal Gafter wrote: > I definitely agree that the semantics of the foreach loop should be > modified to take closability of the iterator into account, but I think it > would be more in the spirit of the existing ARM proposal to do this without > adding a bunch of new interfaces. For example, one approach would be: in a > foreach loop over a collection expression e, if the type of e.iterator() > extends Closeable, then it is automatically closed when the loop exits. > > > On Wed, Oct 21, 2009 at 5:15 AM, Howard Lovatt wrote: > >> Hi, >> >> I have been experimenting in my own code with various 'manual' versions of >> ARM blocks and have found the following interfaces to be useful: >> >> >> in package java.util; >> >> interface Closeable { void close() throws Exception; } >> >> interface CloseableIterable extends Iterable { @Override public >> CloseableIterator iterator(); } >> >> interface CloseableIterator extends Closeable, Iterator {} >> >> interface SafeCloseable extends java.io.Closeable { @Override void >> close(); >> } >> >> interface SafeCloseableIterable extends Iterable { @Override public >> SafeCloseableIterator iterator(); } >> >> interface SafeCloseableIterator extends SafeCloseable, Iterator {} >> >> >> in package java.io; >> >> interface Closeable extends java.util.Closeable { @Override void close() >> throws IOException; } >> >> >> The purpose of the interfaces CloseableIterable and CloseableIterator are >> to >> enable for loops to close resources automatically. A for loop whose >> iteratable is of type CloseableIterable, e.g.: >> >> for ( final E e : closeableIterable ) { ... } >> >> is expanded, using the new ARM block, to: >> >> try ( final CloseableIterator i = closableIterable.iterator() ) { >> while ( i.hasNext() ) { >> final E e = i.next(); >> ... >> } >> } >> >> The semantics of a closed iterator is that hasNext returns false and next >> throws a NoSuchElementException. The purpose of the Safe versions is to >> simplify coding in the, common in my code, cases when close doesn't throw >> an >> exception. Also note that java.io.Closeable is part of the new hierarchy >> for >> backward compatibility and also to allow SafeCloseable's to be passed in >> where java.io.Closeable's are expected. The ARM block only has to deal >> with >> java.util.Closeable, but the for expansion must get the types more exact >> (for expansion already deals with arrays and Iterables so hopefully adding >> CloseableIterable and SafeCloseableIterable won't be too hard). >> >> I have tried trawling the coin archives and I can't find a suggestion >> identical to this (though there are suggestions along these lines), so >> hopefully I haven't missed something in the archive and this is a new >> contribution. >> >> Do others think these interfaces and the for loop suggestion >> useful/viable? >> >> -- Howard. >> >> > From neal at gafter.com Wed Oct 21 09:26:21 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 21 Oct 2009 09:26:21 -0700 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> Message-ID: <15e8b9d20910210926i4f66ac6ew4666415a497c7c59@mail.gmail.com> On Wed, Oct 21, 2009 at 8:39 AM, Joshua Bloch wrote: > I agree that this would be the right way to do it, but I'm not convinced > that it meets the bar for inclusion. It's not a now-or-never thing: its and > independent change to for-each. Unfortunately, the shape of the language will affect the shape of libraries to come, and delaying this aspect of support for Closeable will push libraries in a less-than-optimal direction. It is better to add support for Closeable all at once (or not at all). > Two questions come to mind: > (1) How big a win would this be in terms of expressiveness? How often (in > a real code corpus) would it be applicable. How much nicer would the code > corpus be with this feature. Or is it too magic? (Shorter isn't always > better.) > In C#, the facility is used frequently. Doing it "by hand" has all the disadvantages of boilerplate that both statement forms were meant to eliminate. Going back to a recurring theme: the present design (without supporting the for-each loop) fails to consider future evolution of the language. For example, we'd regret not doing this now if we add support for iterator (or asynchronous) methods in the future. (2) Are there any dangers associated with it? Suppose an existing final > class were retrofitted so that its iterator method returned a closeable > iterator. Then we'd be changing the semantics of an existing for-each over > that resource. Is that a problem? > As explained before, it isn't a problem, primarily because the existence of such code, in conjunction with its use in a for-each loop, represents a resource leak in existing code. I believe you'd be hard pressed to find in production use a single example of the kind of code whose behavior would be changed. From howard.lovatt at iee.org Thu Oct 22 00:23:48 2009 From: howard.lovatt at iee.org (Howard Lovatt) Date: Thu, 22 Oct 2009 09:23:48 +0200 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <15e8b9d20910210926i4f66ac6ew4666415a497c7c59@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> <15e8b9d20910210926i4f66ac6ew4666415a497c7c59@mail.gmail.com> Message-ID: <3dd3f56a0910220023s61776752jdbdfb53ff703b617@mail.gmail.com> I can think of an example were changing the semantics of a for loop would cause problems. If you open a resource, make a first pass over the data collecting statistics, then go back and modify the data as a second pass, and finally close the resource. I doubt this is common, but the example does preclude modifying the for loop to see if a closeable iterator is used. (I suspect as Neal has pointed out that in the majority of cases when people iterate over the resource and don't immediately close it that they simply forgot - but unfortunately there isn't much that can be done about that.) It is for the above reason that I suggested separate types, for example consider a file utility that currently iterates over the lines in a file, this can be retrofitted with an ARM Closeable and an extra method, in addition to the existing iterator from Iterable, that returns a CloseableIterable. This way existing code isn't broken and the new closing for loop construct can be used. Thus adding the extra types gives you fine control. If the extra types I suggested aren't liked then another option would be to allow try to accept for each syntax, e.g. try ( x : resource ) { ... }, as others have suggested. This has the same effect of giving fine control as the extra types and it is a matter of style which is preferred (I have no strong preference). The SafeCloseable type is useful regardless of if anything is done with for-each or not. Without an ARM close that doesn't throw an Exception code that has no need to throw an Exception gets polluted with throws Exception on any method that might close a resource and that then knocks onto methods that call that method etc. You see this same effect with Callable because there is no SafeCallable (Runnable doesn't return a value). Glad to hear the prototype is coming along. -- Howard. 2009/10/21 Neal Gafter > On Wed, Oct 21, 2009 at 8:39 AM, Joshua Bloch wrote: > >> I agree that this would be the right way to do it, but I'm not convinced >> that it meets the bar for inclusion. It's not a now-or-never thing: its and >> independent change to for-each. > > > Unfortunately, the shape of the language will affect the shape of libraries > to come, and delaying this aspect of support for Closeable will push > libraries in a less-than-optimal direction. It is better to add support for > Closeable all at once (or not at all). > > >> Two questions come to mind: >> (1) How big a win would this be in terms of expressiveness? How often >> (in a real code corpus) would it be applicable. How much nicer would the >> code corpus be with this feature. Or is it too magic? (Shorter isn't >> always better.) >> > > In C#, the facility is used frequently. Doing it "by hand" has all the > disadvantages of boilerplate that both statement forms were meant to > eliminate. > > Going back to a recurring theme: the present design (without supporting the > for-each loop) fails to consider future evolution of the language. For > example, we'd regret not doing this now if we add support for iterator (or > asynchronous) methods in the future. > > (2) Are there any dangers associated with it? Suppose an existing final >> class were retrofitted so that its iterator method returned a closeable >> iterator. Then we'd be changing the semantics of an existing for-each over >> that resource. Is that a problem? >> > > As explained before, it isn't a problem, primarily because the existence of > such code, in conjunction with its use in a for-each loop, represents a > resource leak in existing code. I believe you'd be hard pressed to find in > production use a single example of the kind of code whose behavior would be > changed. > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > -- -- Howard. From neal at gafter.com Thu Oct 22 00:33:16 2009 From: neal at gafter.com (Neal Gafter) Date: Thu, 22 Oct 2009 00:33:16 -0700 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <3dd3f56a0910220023s61776752jdbdfb53ff703b617@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> <15e8b9d20910210926i4f66ac6ew4666415a497c7c59@mail.gmail.com> <3dd3f56a0910220023s61776752jdbdfb53ff703b617@mail.gmail.com> Message-ID: <15e8b9d20910220033y6f517dc4g93a3e6b8331eb44c@mail.gmail.com> On Thu, Oct 22, 2009 at 12:23 AM, Howard Lovatt wrote: > I can think of an example were changing the semantics of a for loop would > cause problems. If you open a resource, make a first pass over the data > collecting statistics, then go back and modify the data as a second pass, > and finally close the resource. I doubt this is common, but the example does > preclude modifying the for loop to see if a closeable iterator is used. (I > suspect as Neal has pointed out that in the majority of cases when people > iterate over the resource and don't immediately close it that they simply > forgot - but unfortunately there isn't much that can be done about that.) I can't imagine why such an API would retrofit the Iterator rather than the Iterable with Closeable. Besides being wrong, I expect such code is not just uncommon, but nonexistent. From howard.lovatt at iee.org Thu Oct 22 08:59:17 2009 From: howard.lovatt at iee.org (Howard Lovatt) Date: Thu, 22 Oct 2009 17:59:17 +0200 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <15e8b9d20910220033y6f517dc4g93a3e6b8331eb44c@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> <15e8b9d20910210926i4f66ac6ew4666415a497c7c59@mail.gmail.com> <3dd3f56a0910220023s61776752jdbdfb53ff703b617@mail.gmail.com> <15e8b9d20910220033y6f517dc4g93a3e6b8331eb44c@mail.gmail.com> Message-ID: <3dd3f56a0910220859j39d799c9l1c965ea5ecb9461f@mail.gmail.com> I think you can choose if close to applies to the Iterable or the Iterator. EG consider a user choosing a file and then printing it (or any other example where you want to configure an object and then grab the resource and iterate over it - i.e. lazy grabbing). If close applies to the iterator then you might write: final InFileCloseableIterator cIterator = new InFileCloseableIterator(); cIterator.choose(); // User chooses file for ( final String msg : cIterator ) { // Opens chosen file System.out.println( msg ); } // Closes chosen file If close applied to the Iterable then the action would be split across a choosing object and an Iterable object, e.g.: final FileChooser chooser = new FileChooser(); chooser.choose(); // User chooses file for ( final String msg : new InFileCloseableIterable( chooser ) ) { // Opens chosen file System.out.println( msg ); } // Closes chosen file The latter example, close applies to Iterable, can also use the current for-each and the proposed try without an expanded for-each fairly easily, e.g.: final FileChooser chooser = new FileChooser(); chooser.choose(); // User chooses file try ( final FileCloseableIterable cIterable = new InFileCloseableIterable( chooser ) ) { // Opens chosen file for ( final String msg : cIterable ) { System.out.println( msg ); } } // Closes chosen file The former example, close applies to Iterator, requires the compiler to do more to expand the for-each (see original post in this thread). I find the former, close applies to Iterator, more in keeping with Java collections; but it is more a matter of taste rather than one is definitely better than the other, or did you have a specific example in mind for why you favor close applying to the Iterable? -- Howard. 2009/10/22 Neal Gafter > On Thu, Oct 22, 2009 at 12:23 AM, Howard Lovatt wrote: > >> I can think of an example were changing the semantics of a for loop would >> cause problems. If you open a resource, make a first pass over the data >> collecting statistics, then go back and modify the data as a second pass, >> and finally close the resource. I doubt this is common, but the example does >> preclude modifying the for loop to see if a closeable iterator is used. (I >> suspect as Neal has pointed out that in the majority of cases when people >> iterate over the resource and don't immediately close it that they simply >> forgot - but unfortunately there isn't much that can be done about that.) > > > I can't imagine why such an API would retrofit the Iterator rather than the > Iterable with Closeable. Besides being wrong, I expect such code is not > just uncommon, but nonexistent. > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > -- -- Howard. From neal at gafter.com Thu Oct 22 09:19:48 2009 From: neal at gafter.com (Neal Gafter) Date: Thu, 22 Oct 2009 09:19:48 -0700 Subject: ARM Blocks: ease of use and for loops In-Reply-To: <3dd3f56a0910220859j39d799c9l1c965ea5ecb9461f@mail.gmail.com> References: <3dd3f56a0910210515u51d78ee3i1099230114abc95d@mail.gmail.com> <15e8b9d20910210808l2a4443f0v24421dd37f5d11b9@mail.gmail.com> <17b2302a0910210839n7f06d584y6db7262ecc990775@mail.gmail.com> <15e8b9d20910210926i4f66ac6ew4666415a497c7c59@mail.gmail.com> <3dd3f56a0910220023s61776752jdbdfb53ff703b617@mail.gmail.com> <15e8b9d20910220033y6f517dc4g93a3e6b8331eb44c@mail.gmail.com> <3dd3f56a0910220859j39d799c9l1c965ea5ecb9461f@mail.gmail.com> Message-ID: <15e8b9d20910220919j5a0e1cdfk43f6acd65d601720@mail.gmail.com> On Thu, Oct 22, 2009 at 8:59 AM, Howard Lovatt wrote: > I think you can choose if close to applies to the Iterable or the Iterator. Agreed. But if it applies to the Iterable, the programmer can easily use an ARM block around the for-each loop. If it applies to the Iterator, there is no way for the programmer to do it. That's why support is needed in that case. From Barry at Burd.org Sun Oct 25 18:14:10 2009 From: Barry at Burd.org (Barry Burd) Date: Sun, 25 Oct 2009 21:14:10 -0400 Subject: Reference implementation Message-ID: <4AE4BFA2.618A.0054.0@Burd.org> Is the latest Java 7 build (currently build 74) the most up-to-date implementation of the Project Coin features? From jjb at google.com Sun Oct 25 18:41:11 2009 From: jjb at google.com (Joshua Bloch) Date: Sun, 25 Oct 2009 18:41:11 -0700 Subject: Reference implementation In-Reply-To: <4AE4BFA2.618A.0054.0@Burd.org> References: <4AE4BFA2.618A.0054.0@Burd.org> Message-ID: <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> Barry, Many features (including ARM blocks) aren't in yet. Josh On Sun, Oct 25, 2009 at 6:14 PM, Barry Burd wrote: > Is the latest Java 7 build (currently build 74) the most up-to-date > implementation of the Project Coin features? > > From neal at gafter.com Sun Oct 25 19:04:27 2009 From: neal at gafter.com (Neal Gafter) Date: Sun, 25 Oct 2009 19:04:27 -0700 Subject: Reference implementation In-Reply-To: <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> References: <4AE4BFA2.618A.0054.0@Burd.org> <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> Message-ID: <15e8b9d20910251904i1f0f27f4jbdba4abc74b89268@mail.gmail.com> As I understand the openjdk7 timeline, language features whose implementations are not integrated into the tl workspace by now are too late to be included in JDK7. I fully expect the timeline will be modified imminently. Cheers, Neal On Sun, Oct 25, 2009 at 6:41 PM, Joshua Bloch wrote: > Barry, > > Many features (including ARM blocks) aren't in yet. > > Josh > > On Sun, Oct 25, 2009 at 6:14 PM, Barry Burd wrote: > > > Is the latest Java 7 build (currently build 74) the most up-to-date > > implementation of the Project Coin features? > > > > > > From Barry at Burd.org Sun Oct 25 19:28:17 2009 From: Barry at Burd.org (Barry Burd) Date: Sun, 25 Oct 2009 22:28:17 -0400 Subject: Reference implementation In-Reply-To: <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> References: <4AE4BFA2.618A.0054.0@Burd.org> <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> Message-ID: <4AE4D101.618A.0054.0@Burd.org> Is there an official list of the features that have (and haven't) been integrated into the t1 workspace in time for JDK 7? From Joe.Darcy at Sun.COM Sun Oct 25 22:13:01 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Sun, 25 Oct 2009 22:13:01 -0700 Subject: Reference implementation In-Reply-To: <4AE4D101.618A.0054.0@Burd.org> References: <4AE4BFA2.618A.0054.0@Burd.org> <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> <4AE4D101.618A.0054.0@Burd.org> Message-ID: <4AE52FDD.9090801@sun.com> Barry Burd wrote: > Is there an official list of the features that have (and haven't) been integrated into the t1 workspace in time for JDK 7? > Language support for JSR 292, the diamond operator, and the first part of improve integer literals have been integrated into JDK 7. The set of language changes for Coin remains the one at http://blogs.sun.com/darcy/entry/project_coin_final_five * Strings in switch * Automatic Resource Management * Improved Type Inference for Generic Instance Creation (diamond) * Simplified Varargs Method Invocation * An omnibus proposal for better integral literals * Language support for Collections * Language support for JSR 292 Any changes in the feature list for Project Coin will be made on this list and my blog. -Joe From neal at gafter.com Sun Oct 25 22:51:18 2009 From: neal at gafter.com (Neal Gafter) Date: Sun, 25 Oct 2009 22:51:18 -0700 Subject: Reference implementation In-Reply-To: <4AE52FDD.9090801@sun.com> References: <4AE4BFA2.618A.0054.0@Burd.org> <17b2302a0910251841g360d89f3j45187c34904c43b1@mail.gmail.com> <4AE4D101.618A.0054.0@Burd.org> <4AE52FDD.9090801@sun.com> Message-ID: <15e8b9d20910252251i5ff50026uff7a8c6aefd83462@mail.gmail.com> Joe- Do you expect the implementation of these features to be integrated into the master workspace for the "feature complete" milestone on Thursday? If not, how do you expect to reconcile reality with the schedule? Will the contents change, the schedule, or some of each? Regarding the diamond operator: as we've discussed, the current prototype uses a technique that is incompatible with a possible future extension of type inference to argument contexts. I haven't heard anything about how that might be reconciled. What are your plans? -Neal On Sun, Oct 25, 2009 at 10:13 PM, Joseph D. Darcy wrote: > Barry Burd wrote: > > Is there an official list of the features that have (and haven't) been > integrated into the t1 workspace in time for JDK 7? > > > > Language support for JSR 292, the diamond operator, and the first part > of improve integer literals have been integrated into JDK 7. The set of > language changes for Coin remains the one at > > http://blogs.sun.com/darcy/entry/project_coin_final_five > > * Strings in switch > * Automatic Resource Management > * Improved Type Inference for Generic Instance Creation (diamond) > * Simplified Varargs Method Invocation > * An omnibus proposal for better integral literals > * Language support for Collections > * Language support for JSR 292 > > Any changes in the feature list for Project Coin will be made on this > list and my blog. > > -Joe > > > From pbenedict at apache.org Mon Oct 26 09:51:30 2009 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 26 Oct 2009 11:51:30 -0500 Subject: Reference implementation Message-ID: Neal, Thank you for raising this point again! It was admitted the current diamond operator implementation is incomplete compared to the "complex/full" solution. It was also admitted the partial solution is not a "true subset" of the "complex" solution. With that said, I am concerned the partial solution will infer somethings in JDK 7, but a later JDK using the "complex" solution would infer differently or invalidate inferences of the partial solution. Joe, is that possible? Paul From Maurizio.Cimadamore at Sun.COM Mon Oct 26 10:04:10 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Mon, 26 Oct 2009 17:04:10 +0000 Subject: Reference implementation In-Reply-To: References: Message-ID: <4AE5D68A.6020503@sun.com> Paul Benedict wrote: > Neal, > > Thank you for raising this point again! > > It was admitted the current diamond operator implementation is > incomplete compared to the "complex/full" solution. It was also > admitted the partial solution is not a "true subset" of the "complex" > solution. With that said, I am concerned the partial solution will > infer somethings in JDK 7, but a later JDK using the "complex" > solution would infer differently or invalidate inferences of the > partial solution. Joe, is that possible? > Both complex and simple are subset of full-complex. If some future release will switch to full-complex the transition will be smooth (no strange mismatch in types inferred by the diamond algotithm). On the other hand switching from simple to complex and vice-versa will cause problems. Maurizio > Paul > > From neal at gafter.com Tue Oct 27 16:50:47 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 27 Oct 2009 16:50:47 -0700 Subject: Reference implementation In-Reply-To: <4AE5D68A.6020503@sun.com> References: <4AE5D68A.6020503@sun.com> Message-ID: <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> Maurizio: Can you please define the "complex", "simple", and "full-complex" approaches? Which is used in the current implementation? Which approach can support inference in argument contexts (i.e. part occurs before overload resolution, part after)? Cheers, Neal On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore < Maurizio.Cimadamore at sun.com> wrote: > Paul Benedict wrote: > > Neal, > > > > Thank you for raising this point again! > > > > It was admitted the current diamond operator implementation is > > incomplete compared to the "complex/full" solution. It was also > > admitted the partial solution is not a "true subset" of the "complex" > > solution. With that said, I am concerned the partial solution will > > infer somethings in JDK 7, but a later JDK using the "complex" > > solution would infer differently or invalidate inferences of the > > partial solution. Joe, is that possible? > > > Both complex and simple are subset of full-complex. If some future > release will switch to full-complex the transition will be smooth (no > strange mismatch in types inferred by the diamond algotithm). On the > other hand switching from simple to complex and vice-versa will cause > problems. > > Maurizio > > Paul > > > > > > > From Jonathan.Gibbons at Sun.COM Tue Oct 27 17:16:05 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 27 Oct 2009 17:16:05 -0700 Subject: Reference implementation In-Reply-To: <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> Message-ID: <4AE78D45.6000206@sun.com> Neal, Maurizio defined these terms in emails to coin-dev round about Aug 22. "simple" and "complex" are defined here: http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html I believe "full-complex" first appeared here: http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html I'll leave Maurizio to provide any updates on the terminology. -- Jon Neal Gafter wrote: > Maurizio: > > Can you please define the "complex", "simple", and "full-complex" > approaches? Which is used in the current implementation? Which approach > can support inference in argument contexts (i.e. part occurs before overload > resolution, part after)? > > Cheers, > Neal > > On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore < > Maurizio.Cimadamore at sun.com> wrote: > > >> Paul Benedict wrote: >> >>> Neal, >>> >>> Thank you for raising this point again! >>> >>> It was admitted the current diamond operator implementation is >>> incomplete compared to the "complex/full" solution. It was also >>> admitted the partial solution is not a "true subset" of the "complex" >>> solution. With that said, I am concerned the partial solution will >>> infer somethings in JDK 7, but a later JDK using the "complex" >>> solution would infer differently or invalidate inferences of the >>> partial solution. Joe, is that possible? >>> >>> >> Both complex and simple are subset of full-complex. If some future >> release will switch to full-complex the transition will be smooth (no >> strange mismatch in types inferred by the diamond algotithm). On the >> other hand switching from simple to complex and vice-versa will cause >> problems. >> >> Maurizio >> >>> Paul >>> >>> >>> >> >> > > From neal at gafter.com Tue Oct 27 17:43:07 2009 From: neal at gafter.com (Neal Gafter) Date: Tue, 27 Oct 2009 17:43:07 -0700 Subject: Reference implementation In-Reply-To: <4AE78D45.6000206@sun.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> Message-ID: <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> I see. Based on that, it appears that the "full-complex" approach can't be generalized to argument contexts (because inference results would be required for overload resolution, but overload resolution results would be required for inference). Therefore if we want to support inference in argument contexts in the future, the choice is between "simple" and "complex". Given that they are incompatible, and only the "complex" approach generalizes to argument contexts, we seem to have integrated the wrong approach into the code base. So, taking the future evolution of the language into consideration, what plans are there to revise the prototype? Cheers, Neal On Tue, Oct 27, 2009 at 5:16 PM, Jonathan Gibbons wrote: > Neal, > > Maurizio defined these terms in emails to coin-dev round about Aug 22. > > "simple" and "complex" are defined here: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html > > I believe "full-complex" first appeared here: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html > > I'll leave Maurizio to provide any updates on the terminology. > > -- Jon > > > > > Neal Gafter wrote: > > Maurizio: > > Can you please define the "complex", "simple", and "full-complex" > approaches? Which is used in the current implementation? Which approach > can support inference in argument contexts (i.e. part occurs before overload > resolution, part after)? > > Cheers, > Neal > > On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore wrote: > > > > Paul Benedict wrote: > > > Neal, > > Thank you for raising this point again! > > It was admitted the current diamond operator implementation is > incomplete compared to the "complex/full" solution. It was also > admitted the partial solution is not a "true subset" of the "complex" > solution. With that said, I am concerned the partial solution will > infer somethings in JDK 7, but a later JDK using the "complex" > solution would infer differently or invalidate inferences of the > partial solution. Joe, is that possible? > > > > Both complex and simple are subset of full-complex. If some future > release will switch to full-complex the transition will be smooth (no > strange mismatch in types inferred by the diamond algotithm). On the > other hand switching from simple to complex and vice-versa will cause > problems. > > Maurizio > > > Paul > > > > > > From Maurizio.Cimadamore at Sun.COM Wed Oct 28 02:26:29 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Wed, 28 Oct 2009 09:26:29 +0000 Subject: Reference implementation In-Reply-To: <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> Message-ID: <4AE80E45.9090802@sun.com> Hi Neal Neal Gafter wrote: > I see. Based on that, it appears that the "full-complex" approach > can't be generalized to argument contexts (because inference results > would be required for overload resolution, but overload resolution > results would be required for inference). Could you please formulate a bit more about the above point? I don't think that "full-complex" cannot be generalized - but of course it means that overload resolution should be extended in order to handle method arguments that have a ForAll type (to speak the javac lingo). This extension would be required anyway if inference is to be extended in order to support more call sites (e.g. argument position). In other words I don't see in the full-complex approach more problems than in expanding the scope of ordinary javac type-inference - and, if the implications of the latter are not so promising, then I'm not so sure about what you refer to when you speak of language evolution in this area. Maurizio > Therefore if we want to support inference in argument contexts in the > future, the choice is between "simple" and "complex". Given that they > are incompatible, and only the "complex" approach generalizes to > argument contexts, we seem to have integrated the wrong approach into > the code base. > > So, taking the future evolution of the language into consideration, > what plans are there to revise the prototype? > > Cheers, > Neal > > On Tue, Oct 27, 2009 at 5:16 PM, Jonathan Gibbons > > wrote: > > Neal, > > Maurizio defined these terms in emails to coin-dev round about Aug 22. > > "simple" and "complex" are defined here: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html > > I believe "full-complex" first appeared here: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html > > I'll leave Maurizio to provide any updates on the terminology. > > -- Jon > > > > > Neal Gafter wrote: >> Maurizio: >> >> Can you please define the "complex", "simple", and "full-complex" >> approaches? Which is used in the current implementation? Which approach >> can support inference in argument contexts (i.e. part occurs before overload >> resolution, part after)? >> >> Cheers, >> Neal >> >> On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore < >> Maurizio.Cimadamore at sun.com > wrote: >> >> >>> Paul Benedict wrote: >>> >>>> Neal, >>>> >>>> Thank you for raising this point again! >>>> >>>> It was admitted the current diamond operator implementation is >>>> incomplete compared to the "complex/full" solution. It was also >>>> admitted the partial solution is not a "true subset" of the "complex" >>>> solution. With that said, I am concerned the partial solution will >>>> infer somethings in JDK 7, but a later JDK using the "complex" >>>> solution would infer differently or invalidate inferences of the >>>> partial solution. Joe, is that possible? >>>> >>>> >>> Both complex and simple are subset of full-complex. If some future >>> release will switch to full-complex the transition will be smooth (no >>> strange mismatch in types inferred by the diamond algotithm). On the >>> other hand switching from simple to complex and vice-versa will cause >>> problems. >>> >>> Maurizio >>> >>>> Paul >>>> >>>> >>>> >>> >> > > From neal at gafter.com Wed Oct 28 09:31:47 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 28 Oct 2009 09:31:47 -0700 Subject: Reference implementation In-Reply-To: <4AE80E45.9090802@sun.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> Message-ID: <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> Maurizio- Here's my concern: Quoting from http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html, inference proceeds in two steps, in this order: 1. inference from actual vs. formal arguments (see JLS 15.12.2.7) 2. inference from return type vs. expected type (see JLS 15.12.2.8) For consistency, any future extension of inference to argument contexts should also proceed in this order - in fact, must proceed in this order because overload resolution depends on the results of the first step, and the results of overload resolution are required to apply the second step. To extend the diamond operator to argument contexts, the diamond operator would have to be changed to proceed in these two phases. The prototype's currently implemented "simple inference" only applies the second of these steps. My concern is that such a future change (inserting a new first phase) to the diamond operator would be incompatible. If that proves true, including the current approach into jdk7 would foreclose a possible future extension of type inference to argument contexts. So, if we want to keep our options open to support inference in argument contexts in the future, we should either (1) Demonstrate that a change from the currently implemented approach to a two-phase approach is not a breaking change, or (2) Use a two-phase approach now. Cheers, Neal On Wed, Oct 28, 2009 at 2:26 AM, Maurizio Cimadamore < Maurizio.Cimadamore at sun.com> wrote: > Hi Neal > > > Neal Gafter wrote: > >> I see. Based on that, it appears that the "full-complex" approach can't >> be generalized to argument contexts (because inference results would be >> required for overload resolution, but overload resolution results would be >> required for inference). >> > Could you please formulate a bit more about the above point? I don't think > that "full-complex" cannot be generalized - but of course it means that > overload resolution should be extended in order to handle method arguments > that have a ForAll type (to speak the javac lingo). This extension would be > required anyway if inference is to be extended in order to support more call > sites (e.g. argument position). In other words I don't see in the > full-complex approach more problems than in expanding the scope of ordinary > javac type-inference - and, if the implications of the latter are not so > promising, then I'm not so sure about what you refer to when you speak of > language evolution in this area. > > Maurizio > > > Therefore if we want to support inference in argument contexts in the >> future, the choice is between "simple" and "complex". Given that they are >> incompatible, and only the "complex" approach generalizes to argument >> contexts, we seem to have integrated the wrong approach into the code base. >> >> So, taking the future evolution of the language into consideration, what >> plans are there to revise the prototype? >> >> Cheers, >> Neal >> >> On Tue, Oct 27, 2009 at 5:16 PM, Jonathan Gibbons < >> Jonathan.Gibbons at sun.com > wrote: >> >> Neal, >> >> Maurizio defined these terms in emails to coin-dev round about Aug 22. >> >> "simple" and "complex" are defined here: >> >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html >> >> I believe "full-complex" first appeared here: >> >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html >> >> I'll leave Maurizio to provide any updates on the terminology. >> >> -- Jon >> >> >> >> >> Neal Gafter wrote: >> >>> Maurizio: >>> >>> Can you please define the "complex", "simple", and "full-complex" >>> approaches? Which is used in the current implementation? Which >>> approach >>> can support inference in argument contexts (i.e. part occurs before >>> overload >>> resolution, part after)? >>> >>> Cheers, >>> Neal >>> >>> On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore < >>> Maurizio.Cimadamore at sun.com > >>> wrote: >>> >>> >>> >>>> Paul Benedict wrote: >>>> >>>> >>>>> Neal, >>>>> >>>>> Thank you for raising this point again! >>>>> >>>>> It was admitted the current diamond operator implementation is >>>>> incomplete compared to the "complex/full" solution. It was also >>>>> admitted the partial solution is not a "true subset" of the >>>>> "complex" >>>>> solution. With that said, I am concerned the partial solution will >>>>> infer somethings in JDK 7, but a later JDK using the "complex" >>>>> solution would infer differently or invalidate inferences of the >>>>> partial solution. Joe, is that possible? >>>>> >>>>> >>>>> >>>> Both complex and simple are subset of full-complex. If some future >>>> release will switch to full-complex the transition will be smooth (no >>>> strange mismatch in types inferred by the diamond algotithm). On the >>>> other hand switching from simple to complex and vice-versa will cause >>>> problems. >>>> >>>> Maurizio >>>> >>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > From Maurizio.Cimadamore at Sun.COM Wed Oct 28 10:56:06 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Wed, 28 Oct 2009 17:56:06 +0000 Subject: Reference implementation In-Reply-To: <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> Message-ID: <4AE885B6.2030604@sun.com> Neal Gafter wrote: > Maurizio- > > Here's my concern: Quoting from > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html, > inference proceeds in two steps, in this order: > > 1. inference from actual vs. formal arguments (see JLS 15.12.2.7) > 2. inference from return type vs. expected type (see JLS 15.12.2.8) > > For consistency, any future extension of inference to argument > contexts should also proceed in this order - in fact, must proceed in > this order because overload resolution depends on the results of the > first step, and the results of overload resolution are required to > apply the second step. Hi Neal When you say that overload resolution depends on the result of the first step, I guess you refer to the fact that both 15.12.2.2, 15.12.2.3 and 15.12.2.4 refer to 15.12.2.7. Well this is not much of a concern - that inference step can be replaced by a full-inference step (round 1 followed by round 2) where the expected type is unspecified. Moreover, we think that it is very important to be able to refactor code like: class Foo { Foo(X x) {...} } Foo fo = new Foo(1); with your proposed approach the above code will give an error (see statistics and results in [1]). If you can think of an extension to your approach so that the above code will be accepted when refactored with diamond I'd be more than happy to discuss in more details. Maurizio [1] - http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html > > To extend the diamond operator to argument contexts, the diamond > operator would have to be changed to proceed in these two phases. The > prototype's currently implemented "simple inference" only applies the > second of these steps. My concern is that such a future change > (inserting a new first phase) to the diamond operator would be > incompatible. If that proves true, including the current approach > into jdk7 would foreclose a possible future extension of type > inference to argument contexts. > > So, if we want to keep our options open to support inference in > argument contexts in the future, we should either (1) Demonstrate that > a change from the currently implemented approach to a two-phase > approach is not a breaking change, or (2) Use a two-phase approach now. > > Cheers, > Neal > > On Wed, Oct 28, 2009 at 2:26 AM, Maurizio Cimadamore > > wrote: > > Hi Neal > > > Neal Gafter wrote: > > I see. Based on that, it appears that the "full-complex" > approach can't be generalized to argument contexts (because > inference results would be required for overload resolution, > but overload resolution results would be required for > inference). > > Could you please formulate a bit more about the above point? I > don't think that "full-complex" cannot be generalized - but of > course it means that overload resolution should be extended in > order to handle method arguments that have a ForAll type (to speak > the javac lingo). This extension would be required anyway if > inference is to be extended in order to support more call sites > (e.g. argument position). In other words I don't see in the > full-complex approach more problems than in expanding the scope of > ordinary javac type-inference - and, if the implications of the > latter are not so promising, then I'm not so sure about what you > refer to when you speak of language evolution in this area. > > Maurizio > > > Therefore if we want to support inference in argument contexts > in the future, the choice is between "simple" and "complex". > Given that they are incompatible, and only the "complex" > approach generalizes to argument contexts, we seem to have > integrated the wrong approach into the code base. > > So, taking the future evolution of the language into > consideration, what plans are there to revise the prototype? > > Cheers, > Neal > > On Tue, Oct 27, 2009 at 5:16 PM, Jonathan Gibbons > > >> wrote: > > Neal, > > Maurizio defined these terms in emails to coin-dev round > about Aug 22. > > "simple" and "complex" are defined here: > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html > > I believe "full-complex" first appeared here: > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html > > I'll leave Maurizio to provide any updates on the terminology. > > -- Jon > > > > > Neal Gafter wrote: > > Maurizio: > > Can you please define the "complex", "simple", and > "full-complex" > approaches? Which is used in the current > implementation? Which approach > can support inference in argument contexts (i.e. part > occurs before overload > resolution, part after)? > > Cheers, > Neal > > On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore < > Maurizio.Cimadamore at sun.com > > >> wrote: > > > > Paul Benedict wrote: > > > Neal, > > Thank you for raising this point again! > > It was admitted the current diamond operator > implementation is > incomplete compared to the "complex/full" > solution. It was also > admitted the partial solution is not a "true > subset" of the "complex" > solution. With that said, I am concerned the > partial solution will > infer somethings in JDK 7, but a later JDK > using the "complex" > solution would infer differently or invalidate > inferences of the > partial solution. Joe, is that possible? > > > > Both complex and simple are subset of full-complex. > If some future > release will switch to full-complex the transition > will be smooth (no > strange mismatch in types inferred by the diamond > algotithm). On the > other hand switching from simple to complex and > vice-versa will cause > problems. > > Maurizio > > > Paul > > > > > > > > > > > > From neal at gafter.com Wed Oct 28 11:13:58 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 28 Oct 2009 11:13:58 -0700 Subject: Reference implementation In-Reply-To: <4AE885B6.2030604@sun.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> Message-ID: <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> On Wed, Oct 28, 2009 at 10:56 AM, Maurizio Cimadamore < Maurizio.Cimadamore at sun.com> wrote: > Neal Gafter wrote: > >> Maurizio- >> >> Here's my concern: Quoting from >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html, >> inference proceeds in two steps, in this order: >> >> 1. inference from actual vs. formal arguments (see JLS 15.12.2.7) >> 2. inference from return type vs. expected type (see JLS 15.12.2.8) >> >> >> For consistency, any future extension of inference to argument contexts >> should also proceed in this order - in fact, must proceed in this order >> because overload resolution depends on the results of the first step, and >> the results of overload resolution are required to apply the second step. >> > Hi Neal > When you say that overload resolution depends on the result of the first > step, I guess you refer to the fact that both 15.12.2.2, 15.12.2.3 and > 15.12.2.4 refer to 15.12.2.7. Well this is not much of a concern - that > inference step can be replaced by a full-inference step (round 1 followed by > round 2) where the expected type is unspecified. > Isn't that basically what is done today? That is, the parameter type is ignored ("unspecified") when performing type inference on a method invocation in an argument context. That is exactly the issue I'm hoping will be fixed in a future extension: the method's (expected) parameter type *should* play a part in the second phase. Moreover, we think that it is very important to be able to refactor code > like: > > class Foo { > Foo(X x) {...} > } > > Foo fo = new Foo(1); > > with your proposed approach the above code will give an error (see > statistics and results in [1]). I see that you conclude, based on those statistics, that "No approach looks noticeably better than the other." Your main reason for preferring the simple approach appears to be that inference in argument positions isn't done, so few benefits accrue to the more complex approach. However, I would hope that consideration of future language evolution - that is, argument inference might be desirable *in the future* - to be a deciding factor. Cheers, Neal From Jonathan.Gibbons at Sun.COM Wed Oct 28 13:41:35 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 28 Oct 2009 13:41:35 -0700 Subject: Reference implementation In-Reply-To: <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> Message-ID: <4AE8AC7F.5040108@sun.com> Neal Gafter wrote: > On Wed, Oct 28, 2009 at 10:56 AM, Maurizio Cimadamore < > Maurizio.Cimadamore at sun.com> wrote: > > >> Neal Gafter wrote: >> >> >>> Maurizio- >>> >>> Here's my concern: Quoting from >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html, >>> inference proceeds in two steps, in this order: >>> >>> 1. inference from actual vs. formal arguments (see JLS 15.12.2.7) >>> 2. inference from return type vs. expected type (see JLS 15.12.2.8) >>> >>> >>> For consistency, any future extension of inference to argument contexts >>> should also proceed in this order - in fact, must proceed in this order >>> because overload resolution depends on the results of the first step, and >>> the results of overload resolution are required to apply the second step. >>> >>> >> Hi Neal >> When you say that overload resolution depends on the result of the first >> step, I guess you refer to the fact that both 15.12.2.2, 15.12.2.3 and >> 15.12.2.4 refer to 15.12.2.7. Well this is not much of a concern - that >> inference step can be replaced by a full-inference step (round 1 followed by >> round 2) where the expected type is unspecified. >> >> > > Isn't that basically what is done today? That is, the parameter type is > ignored ("unspecified") when performing type inference on a method > invocation in an argument context. That is exactly the issue I'm hoping > will be fixed in a future extension: the method's (expected) parameter type > *should* play a part in the second phase. > > Moreover, we think that it is very important to be able to refactor code > >> like: >> >> class Foo { >> Foo(X x) {...} >> } >> >> Foo fo = new Foo(1); >> >> with your proposed approach the above code will give an error (see >> statistics and results in [1]). >> > > > I see that you conclude, based on those statistics, that "No approach looks > noticeably better than the other." Your main reason for preferring the > simple approach appears to be that inference in argument positions isn't > done, so few benefits accrue to the more complex approach. However, I would > hope that consideration of future language evolution - that is, argument > inference might be desirable *in the future* - to be a deciding factor. > > Cheers, > Neal > > Neal, In the short term, we think that the current ("simple") approach is the way to go. Long term, we think we will need something like the "full-complex" approach that Maurizio has described. That will address the need for argument inference. However, we do not have the resources to fully investigate that solution at this point. -- Jon From neal at gafter.com Wed Oct 28 15:36:08 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 28 Oct 2009 15:36:08 -0700 Subject: Reference implementation In-Reply-To: <4AE8AC7F.5040108@sun.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> Message-ID: <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> On Wed, Oct 28, 2009 at 1:41 PM, Jonathan Gibbons wrote: > In the short term, we think that the current ("simple") approach is the > way to go. Long term, we think we will need something like the > "full-complex" approach that Maurizio has described. That will address the > need for argument inference. However, we do not have the resources to fully > investigate that solution at this point. > I don't believe that the full-complex approach is both implementable and upward compatible with the simple approach. However, it hasn't been specified in any detail, so it isn't possible for a demonstration to be made either way. I'm afraid that the currently integrated approach really is painting us into a corner. The "complex" approach is more clearly upward compatible. If there are insufficient resources to fully investigate, the conservative solution would be to implement the "complex" approach (or none at all). I find it remarkable that multi-catch was rejected from Coin for veering too near the type system (even though it doesn't effect the type system), while at the same time decisions about generic type inference are being included in Coin even though we lack the resources to fully investigate their long-term impact. -Neal From Barry at Burd.org Wed Oct 28 23:23:10 2009 From: Barry at Burd.org (Barry Burd) Date: Thu, 29 Oct 2009 02:23:10 -0400 Subject: Reference implementation Message-ID: <4AE8FC8D.618A.0054.0@Burd.org> On Sunday Neal Gafter wrote to Joe Darcy: "Do you expect the implementation of these features to be integrated into the master workspace for the "feature complete" milestone on Thursday? If not, how do you expect to reconcile reality with the schedule? Will the contents change, the schedule, or some of each?" It's Thursday where I live (near NYC) so I'm anxious to know the answers to these questions. Any info? From Maurizio.Cimadamore at Sun.COM Thu Oct 29 02:48:32 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Thu, 29 Oct 2009 09:48:32 +0000 Subject: Reference implementation In-Reply-To: <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> Message-ID: <4AE964F0.10504@sun.com> Neal Gafter wrote: > On Wed, Oct 28, 2009 at 1:41 PM, Jonathan Gibbons > wrote: > > >> In the short term, we think that the current ("simple") approach is the >> way to go. Long term, we think we will need something like the >> "full-complex" approach that Maurizio has described. That will address the >> need for argument inference. However, we do not have the resources to fully >> investigate that solution at this point. >> >> > > I don't believe that the full-complex approach is both implementable and > upward compatible with the simple approach. However, it hasn't been > specified in any detail, so it isn't possible for a demonstration to be made > either way. Neal, the complex-full approach is essentially your approach plus some magic to make the following work: Foo = new Foo<>(1); That is, a complex approach that takes into account the expected return type in order not to infer a type which is too specific. Such an approach would be compatible with the currently implemented simple approach (in fact, ANY other approach that takes into consideration the expected return type would be compatible with the simple approach). I see your point about choosing between usability and language evolution. To be honest this seems quite a small price to pay compared to other choices that have been made for Java w.r.t. to language evolution. To name 3: 1) support for generic cast w/o reification and raw types --> have made reification nearly impossible 2) wildcards --> despite their usefulness when writing library methods they have made the type-system undecidable (well we don't have a full proof yet, but certainly we have bugs) 3) addiction of synthetic types (captured/intersection types) for better type-inference --> lead to infinite types and, again, makes it really hard to discuss seriously about reification In other words I don't think that the current implementation of diamond should be blamed for putting Java into the corner. As a side-issue consider also that the complex approach, and any other inference approach taking into account actual argument types, has the ''drawback'' of inferring captured types as possible instantiation for a generic type. E.g. void m(List ls) { Foo f = new Foo<>(ls.head); //inferred as Foo<#1>, where #1 extends Object } Again I don't think that is is particularly good in term of language evolution - what does it mean to create an instance of a generic type parameterized with a captured type? What should the runtime semantics of Foo<#1> be (assuming you have reification) ? The simple approach is not corner case-free - there are circumstances in which simple infers an intersection type, e.g. if the class type-variable has multiple bounds - but it is definitively better than having to support intersection types AND captured types at the same type. Maurizio > I'm afraid that the currently integrated approach really is > painting us into a corner. The "complex" approach is more clearly upward > compatible. If there are insufficient resources to fully investigate, the > conservative solution would be to implement the "complex" approach (or none > at all). > > I find it remarkable that multi-catch was rejected from Coin for veering too > near the type system (even though it doesn't effect the type system), while > at the same time decisions about generic type inference are being included > in Coin even though we lack the resources to fully investigate their > long-term impact. > > -Neal > > From reinier at zwitserloot.com Thu Oct 29 07:08:32 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Thu, 29 Oct 2009 14:08:32 +0000 Subject: Reference implementation In-Reply-To: <4AE964F0.10504@sun.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> Message-ID: <0506FD1F-0E88-4517-BAA3-ABDCA77D2BC8@zwitserloot.com> Actually, those 3 examples don't seem too bad for future expansion. Sure, reification is a hard nut to crack, but it always has been. Specifically: Java5 allowing unchecked generics casts isn't a big issue, as far as I can see. A hypothetical future version of java that does have reification (call it javaX) can migrate via either of two options: 1. Use a different mechanic for casting-with-checking. Presumably javaX has a new type concept (something like super type tokens but less unwieldly), so instead of writing (List)someList;, you might write List.type.cast(someList); The nature of generics casting is inherently complicated, so the notion that this syntax isn't like the other java syntax is simply unavoidable; where without generics there's only one casting concept, with generics there are at least 2, so at least one of them is going to not be like the status quo. Example: List list = Collections.unmodifiableList(Arrays.asList(1, 2, 3, 4, 5)); List integerList = (List)list; With reification, a cast-with-reification-check would fail, as the runtime type of 'list' is List, which isn't compatible with List. However, as a practical matter, coercing 'list' into the List type couldn't possibly go wrong: It does actually contain only integers, and it's unmodifiable*. Thus, the existing concept of coercing the generics bounds remains a useful operation, but it's different from casting in a reified java. Thus, the argument that 'List.type.cast(someList)' doesn't fit existing java syntax is valid, but there won't be a solution that uniformly fits anyway, so it's a moot point. 2. Due to other incompatibilities between reified and unreified generics, java-with-reification is syntax-wise never going to play well with unreified generics. The solution is to put a 'style reified;' or 'version X;' at the top of your java sources to indicate you want the meaning of , casts, etc to mean: reified behaviour. This solution will work for just about everything (including full-complex vs. complex vs. simple resolution of the diamond operator), of course, but the serious issues with reification back when Java5 was released means there's a good reason to go that far. The relative difficulty between getting the simple vs. complex vs. full-complex issue sorted out right now aren't even in the same ballpark. The wildcard issue also refers to generics, and clearly you need them. Only if someone raised this issue when generics were designed, AND offered a viable alternative, would the wildcard issue be analogous to this issue. I'm not familiar enough with captured types, but my experience with generics is that when inference works right, your code is obvious (and I have a _really_ hard time imagining how any smarter inference system is going to break existing code, given that the inferencer is so poor today), and I take it that backwards compatibility doesn't extend to keeping the compiler error messages the same between releases of javac. I don't see how intersection types interfere with future java improvements. Also, when intersection types were designed, did anyone raise this issue AND offer a viable alternative? Without both of those conditions being true, it clearly does not parallel the current situation. If you want a good example of how a past java design decision gets in the way of improvements now, look no further than overloading. Half the new features I think up for Project Lombok only work with a rider that you can't overload your methods. (Examples: default parameters, named parameters, method reference literals, closure-by-method-ref). Having said all of this, if you assert that your current plan for implementing this feature WILL be future compatible with a better inference style with no unfortunate gotchas, then this entire discussion seems somewhat moot :P --Reinier Zwitserloot *) Presuming that the original list reference is tossed, so that no code can add non-integers to this list. On 2009/29/10, at 09:48, Maurizio Cimadamore wrote: > Neal Gafter wrote: >> On Wed, Oct 28, 2009 at 1:41 PM, Jonathan Gibbons >> wrote: >> >> >>> In the short term, we think that the current ("simple") approach >>> is the >>> way to go. Long term, we think we will need something like the >>> "full-complex" approach that Maurizio has described. That will >>> address the >>> need for argument inference. However, we do not have the resources >>> to fully >>> investigate that solution at this point. >>> >>> >> >> I don't believe that the full-complex approach is both >> implementable and >> upward compatible with the simple approach. However, it hasn't been >> specified in any detail, so it isn't possible for a demonstration >> to be made >> either way. > Neal, the complex-full approach is essentially your approach plus some > magic to make the following work: > > Foo = new Foo<>(1); > > That is, a complex approach that takes into account the expected > return > type in order not to infer a type which is too specific. Such an > approach would be compatible with the currently implemented simple > approach (in fact, ANY other approach that takes into consideration > the > expected return type would be compatible with the simple approach). > > I see your point about choosing between usability and language > evolution. To be honest this seems quite a small price to pay compared > to other choices that have been made for Java w.r.t. to language > evolution. To name 3: > > 1) support for generic cast w/o reification and raw types --> have > made > reification nearly impossible > 2) wildcards --> despite their usefulness when writing library methods > they have made the type-system undecidable (well we don't have a full > proof yet, but certainly we have bugs) > 3) addiction of synthetic types (captured/intersection types) for > better > type-inference --> lead to infinite types and, again, makes it really > hard to discuss seriously about reification > > In other words I don't think that the current implementation of > diamond > should be blamed for putting Java into the corner. As a side-issue > consider also that the complex approach, and any other inference > approach taking into account actual argument types, has the > ''drawback'' > of inferring captured types as possible instantiation for a generic > type. E.g. > > void m(List ls) { > Foo f = new Foo<>(ls.head); //inferred as Foo<#1>, where #1 > extends Object > } > > Again I don't think that is is particularly good in term of language > evolution - what does it mean to create an instance of a generic type > parameterized with a captured type? What should the runtime > semantics of > Foo<#1> be (assuming you have reification) ? > > The simple approach is not corner case-free - there are > circumstances in > which simple infers an intersection type, e.g. if the class > type-variable has multiple bounds - but it is definitively better than > having to support intersection types AND captured types at the same > type. > > Maurizio > >> I'm afraid that the currently integrated approach really is >> painting us into a corner. The "complex" approach is more clearly >> upward >> compatible. If there are insufficient resources to fully >> investigate, the >> conservative solution would be to implement the "complex" approach >> (or none >> at all). >> >> I find it remarkable that multi-catch was rejected from Coin for >> veering too >> near the type system (even though it doesn't effect the type >> system), while >> at the same time decisions about generic type inference are being >> included >> in Coin even though we lack the resources to fully investigate their >> long-term impact. >> >> -Neal >> >> > > From Maurizio.Cimadamore at Sun.COM Thu Oct 29 08:13:21 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Thu, 29 Oct 2009 15:13:21 +0000 Subject: Reference implementation In-Reply-To: <0506FD1F-0E88-4517-BAA3-ABDCA77D2BC8@zwitserloot.com> References: <4AE5D68A.6020503@sun.com> <15e8b9d20910271650v1186becetf0ac3388647ac08e@mail.gmail.com> <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> <0506FD1F-0E88-4517-BAA3-ABDCA77D2BC8@zwitserloot.com> Message-ID: <4AE9B111.40105@sun.com> Reinier Zwitserloot wrote: > Actually, those 3 examples don't seem too bad for future expansion. > Sure, reification is a hard nut to crack, but it always has been. Just to clarify - I said that these 3 decisions have made reification *nearly* impossible - not impossible at all. I guess that the length of your proposal for dealing with cast speak for itself (if we need to kinda workaround to the fact that now it's possible to write generic cast even without reification support that means that the decision does jeopardize further language evolution - e.g it prevents reified Java from using classic syntax for casts - note that this problem does not occur with instanceof). As far as my other two issues - I'm not concerned about typing and safety - what I'm concerned about is performances - if you have instances of Foo<#1> or Foo<#1 extends Object & Comparable > are you sure that the VM could still perform decently? The Java subtyping algorithm with generics and wildcards is complex enough that it suffices a bit of twists and turns to make javac to run out of Stack (even in cases where subtyping can be proved). What does that mean to have such a subtyping test inside the JVM ? That's what I'm worried about. Maurizio > > Specifically: > > Java5 allowing unchecked generics casts isn't a big issue, as far as I > can see. A hypothetical future version of java that does have > reification (call it javaX) can migrate via either of two options: > > 1. Use a different mechanic for casting-with-checking. Presumably > javaX has a new type concept (something like super type tokens but > less unwieldly), so instead of writing (List)someList;, you > might write List.type.cast(someList); The nature of generics > casting is inherently complicated, so the notion that this syntax > isn't like the other java syntax is simply unavoidable; where without > generics there's only one casting concept, with generics there are at > least 2, so at least one of them is going to not be like the status > quo. Example: > > List list = > Collections.unmodifiableList(Arrays.asList(1, 2, 3, 4, > 5)); > List integerList = (List)list; > > With reification, a cast-with-reification-check would fail, as the > runtime type of 'list' is List, which isn't compatible with > List. However, as a practical matter, coercing 'list' into > the List type couldn't possibly go wrong: It does actually > contain only integers, and it's unmodifiable*. Thus, the existing > concept of coercing the generics bounds remains a useful operation, > but it's different from casting in a reified java. > > Thus, the argument that 'List.type.cast(someList)' doesn't fit > existing java syntax is valid, but there won't be a solution that > uniformly fits anyway, so it's a moot point. > > 2. Due to other incompatibilities between reified and unreified > generics, java-with-reification is syntax-wise never going to play > well with unreified generics. The solution is to put a 'style > reified;' or 'version X;' at the top of your java sources to indicate > you want the meaning of , casts, etc to mean: reified > behaviour. This solution will work for just about everything > (including full-complex vs. complex vs. simple resolution of the > diamond operator), of course, but the serious issues with reification > back when Java5 was released means there's a good reason to go that > far. The relative difficulty between getting the simple vs. complex > vs. full-complex issue sorted out right now aren't even in the same > ballpark. > > > The wildcard issue also refers to generics, and clearly you need them. > Only if someone raised this issue when generics were designed, AND > offered a viable alternative, would the wildcard issue be analogous to > this issue. > > > I'm not familiar enough with captured types, but my experience with > generics is that when inference works right, your code is obvious (and > I have a _really_ hard time imagining how any smarter inference system > is going to break existing code, given that the inferencer is so poor > today), and I take it that backwards compatibility doesn't extend to > keeping the compiler error messages the same between releases of javac. > > I don't see how intersection types interfere with future java > improvements. Also, when intersection types were designed, did anyone > raise this issue AND offer a viable alternative? Without both of those > conditions being true, it clearly does not parallel the current situation. > > > If you want a good example of how a past java design decision gets in > the way of improvements now, look no further than overloading. Half > the new features I think up for Project Lombok only work with a rider > that you can't overload your methods. (Examples: default parameters, > named parameters, method reference literals, closure-by-method-ref). > > Having said all of this, if you assert that your current plan for > implementing this feature WILL be future compatible with a better > inference style with no unfortunate gotchas, then this entire > discussion seems somewhat moot :P > > --Reinier Zwitserloot > > *) Presuming that the original list reference is tossed, so that no > code can add non-integers to this list. > > > On 2009/29/10, at 09:48, Maurizio Cimadamore wrote: > >> Neal Gafter wrote: >>> On Wed, Oct 28, 2009 at 1:41 PM, Jonathan Gibbons >>> >wrote: >>> >>> >>>> In the short term, we think that the current ("simple") approach is the >>>> way to go. Long term, we think we will need something like the >>>> "full-complex" approach that Maurizio has described. That will >>>> address the >>>> need for argument inference. However, we do not have the resources >>>> to fully >>>> investigate that solution at this point. >>>> >>>> >>> >>> I don't believe that the full-complex approach is both implementable and >>> upward compatible with the simple approach. However, it hasn't been >>> specified in any detail, so it isn't possible for a demonstration to >>> be made >>> either way. >> Neal, the complex-full approach is essentially your approach plus some >> magic to make the following work: >> >> Foo = new Foo<>(1); >> >> That is, a complex approach that takes into account the expected return >> type in order not to infer a type which is too specific. Such an >> approach would be compatible with the currently implemented simple >> approach (in fact, ANY other approach that takes into consideration the >> expected return type would be compatible with the simple approach). >> >> I see your point about choosing between usability and language >> evolution. To be honest this seems quite a small price to pay compared >> to other choices that have been made for Java w.r.t. to language >> evolution. To name 3: >> >> 1) support for generic cast w/o reification and raw types --> have made >> reification nearly impossible >> 2) wildcards --> despite their usefulness when writing library methods >> they have made the type-system undecidable (well we don't have a full >> proof yet, but certainly we have bugs) >> 3) addiction of synthetic types (captured/intersection types) for better >> type-inference --> lead to infinite types and, again, makes it really >> hard to discuss seriously about reification >> >> In other words I don't think that the current implementation of diamond >> should be blamed for putting Java into the corner. As a side-issue >> consider also that the complex approach, and any other inference >> approach taking into account actual argument types, has the ''drawback'' >> of inferring captured types as possible instantiation for a generic >> type. E.g. >> >> void m(List ls) { >> Foo f = new Foo<>(ls.head); //inferred as Foo<#1>, where #1 >> extends Object >> } >> >> Again I don't think that is is particularly good in term of language >> evolution - what does it mean to create an instance of a generic type >> parameterized with a captured type? What should the runtime semantics of >> Foo<#1> be (assuming you have reification) ? >> >> The simple approach is not corner case-free - there are circumstances in >> which simple infers an intersection type, e.g. if the class >> type-variable has multiple bounds - but it is definitively better than >> having to support intersection types AND captured types at the same type. >> >> Maurizio >> >>> I'm afraid that the currently integrated approach really is >>> painting us into a corner. The "complex" approach is more clearly >>> upward >>> compatible. If there are insufficient resources to fully >>> investigate, the >>> conservative solution would be to implement the "complex" approach >>> (or none >>> at all). >>> >>> I find it remarkable that multi-catch was rejected from Coin for >>> veering too >>> near the type system (even though it doesn't effect the type >>> system), while >>> at the same time decisions about generic type inference are being >>> included >>> in Coin even though we lack the resources to fully investigate their >>> long-term impact. >>> >>> -Neal >>> >>> >> >> > From neal at gafter.com Thu Oct 29 08:18:50 2009 From: neal at gafter.com (Neal Gafter) Date: Thu, 29 Oct 2009 08:18:50 -0700 Subject: Reference implementation In-Reply-To: <4AE964F0.10504@sun.com> References: <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> Message-ID: <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore < Maurizio.Cimadamore at sun.com> wrote: > Neal, the complex-full approach is essentially your approach plus some > magic to make the following work: > > Foo = new Foo<>(1); > > That is, a complex approach that takes into account the expected return > type in order not to infer a type which is too specific. Such an approach > would be compatible with the currently implemented simple approach (in fact, > ANY other approach that takes into consideration the expected return type > would be compatible with the simple approach). > Are you telling me that you're confident that such "magic" can be specified, and implemented, and retrofitted onto the implementation of generic method invocations and argument contexts, without any deep issues? If so, I'm satisfied. > I see your point about choosing between usability and language evolution. > To be honest this seems quite a small price to pay compared to other choices > that have been made for Java w.r.t. to language evolution. To name 3: > I've never bought arguments of the form "things are bad now, so there's no problem making them worse." As a side-issue consider also that the complex approach, and any other > inference approach taking into account actual argument types, has the > ''drawback'' of inferring captured types as possible instantiation for a > generic type. E.g. > > void m(List ls) { > Foo f = new Foo<>(ls.head); //inferred as Foo<#1>, where #1 extends > Object > } > > Again I don't think that is is particularly good in term of language > evolution - what does it mean to create an instance of a generic type > parameterized with a captured type? What should the runtime semantics of > Foo<#1> be (assuming you have reification) ? > This is the same question as *existing *type inference for generic methods, and I would expect the answer to be the same. Captured types represent types that, under reification, are available at runtime. I would expect #1's type to be taken from the element type of the incoming list. I suspect that's naive. But I also expect (and hope) that inference in argument contexts is a much more likely and imminent future extension than reification. The simple approach is not corner case-free - there are circumstances in > which simple infers an intersection type, e.g. if the class type-variable > has multiple bounds - but it is definitively better than having to support > intersection types AND captured types at the same type. > Given that generic method type inference already does all that, I don't see that you've simplified anything. -Neal From Maurizio.Cimadamore at Sun.COM Thu Oct 29 08:37:08 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Thu, 29 Oct 2009 15:37:08 +0000 Subject: Reference implementation In-Reply-To: <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> References: <4AE78D45.6000206@sun.com> <15e8b9d20910271743l468cd2aaua4dffd56c711fc65@mail.gmail.com> <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> Message-ID: <4AE9B6A4.6030007@sun.com> Neal Gafter wrote: > On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore > > wrote: > > Neal, the complex-full approach is essentially your approach plus > some magic to make the following work: > > Foo = new Foo<>(1); > > That is, a complex approach that takes into account the expected > return type in order not to infer a type which is too specific. > Such an approach would be compatible with the currently > implemented simple approach (in fact, ANY other approach that > takes into consideration the expected return type would be > compatible with the simple approach). > > > Are you telling me that you're confident that such "magic" can be > specified, and implemented, and retrofitted onto the implementation of > generic method invocations and argument contexts, without any deep > issues? If so, I'm satisfied. I think such an approach does exist - on the other hand if it didn't, it would mean that there is no way (other than the simple approach) to support the use case I mentioned several times in this thread. Maurizio From pbenedict at apache.org Thu Oct 29 08:53:06 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 29 Oct 2009 10:53:06 -0500 Subject: Reference implementation In-Reply-To: <4AE9B6A4.6030007@sun.com> References: <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> <4AE9B6A4.6030007@sun.com> Message-ID: I think Neal is asking for proof, but the responses given to him are in the "I believe" category. Is there some way to prove that the "full complex" approach is not cornered out? Paul On Thu, Oct 29, 2009 at 10:37 AM, Maurizio Cimadamore wrote: > Neal Gafter wrote: >> >> On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore >> > wrote: >> >> ? ?Neal, the complex-full approach is essentially your approach plus >> ? ?some magic to make the following work: >> >> ? ?Foo = new Foo<>(1); >> >> ? ?That is, a complex approach that takes into account the expected >> ? ?return type in order not to infer a type which is too specific. >> ? ?Such an approach would be compatible with the currently >> ? ?implemented simple approach (in fact, ANY other approach that >> ? ?takes into consideration the expected return type would be >> ? ?compatible with the simple approach). >> >> >> Are you telling me that you're confident that such "magic" can be >> specified, and implemented, and retrofitted onto the implementation of >> generic method invocations and argument contexts, without any deep issues? >> ?If so, I'm satisfied. > > I think such an approach does exist - on the other hand if it didn't, it > would mean that there is no way (other than the simple approach) to support > the use case I mentioned several times in this thread. > > Maurizio > > From Maurizio.Cimadamore at Sun.COM Thu Oct 29 09:04:34 2009 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Thu, 29 Oct 2009 16:04:34 +0000 Subject: Reference implementation In-Reply-To: References: <4AE80E45.9090802@sun.com> <15e8b9d20910280931wccbf47fm207ed116faab7dc3@mail.gmail.com> <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> <4AE9B6A4.6030007@sun.com> Message-ID: <4AE9BD12.7050205@sun.com> Paul Benedict wrote: > I think Neal is asking for proof, but the responses given to him are > in the "I believe" category. Is there some way to prove that the "full > complex" approach is not cornered out? > What do you exactly mean by cornered out? Maurizio > Paul > > On Thu, Oct 29, 2009 at 10:37 AM, Maurizio Cimadamore > wrote: > >> Neal Gafter wrote: >> >>> On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore >>> > wrote: >>> >>> Neal, the complex-full approach is essentially your approach plus >>> some magic to make the following work: >>> >>> Foo = new Foo<>(1); >>> >>> That is, a complex approach that takes into account the expected >>> return type in order not to infer a type which is too specific. >>> Such an approach would be compatible with the currently >>> implemented simple approach (in fact, ANY other approach that >>> takes into consideration the expected return type would be >>> compatible with the simple approach). >>> >>> >>> Are you telling me that you're confident that such "magic" can be >>> specified, and implemented, and retrofitted onto the implementation of >>> generic method invocations and argument contexts, without any deep issues? >>> If so, I'm satisfied. >>> >> I think such an approach does exist - on the other hand if it didn't, it >> would mean that there is no way (other than the simple approach) to support >> the use case I mentioned several times in this thread. >> >> Maurizio >> >> >> > > From howard.lovatt at iee.org Thu Oct 29 09:04:25 2009 From: howard.lovatt at iee.org (Howard Lovatt) Date: Thu, 29 Oct 2009 17:04:25 +0100 Subject: Reference implementation Message-ID: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> Wouldn't it be simpler to introduce a source statement in Coin, forget the diamond operator, and get 7 out. Having introduced source, 8 can be incompatible with previous Java versions (except at the JVM level), wildcards dropped, generics reified, and type inference for methods and declarations improved. -- Howard. ---------- Forwarded message ---------- From: Maurizio Cimadamore To: Reinier Zwitserloot Date: Thu, 29 Oct 2009 15:13:21 +0000 Subject: Re: Reference implementation Reinier Zwitserloot wrote: > Actually, those 3 examples don't seem too bad for future expansion. Sure, > reification is a hard nut to crack, but it always has been. > Just to clarify - I said that these 3 decisions have made reification *nearly* impossible - not impossible at all. I guess that the length of your proposal for dealing with cast speak for itself (if we need to kinda workaround to the fact that now it's possible to write generic cast even without reification support that means that the decision does jeopardize further language evolution - e.g it prevents reified Java from using classic syntax for casts - note that this problem does not occur with instanceof). As far as my other two issues - I'm not concerned about typing and safety - what I'm concerned about is performances - if you have instances of Foo<#1> or Foo<#1 extends Object & Comparable > are you sure that the VM could still perform decently? The Java subtyping algorithm with generics and wildcards is complex enough that it suffices a bit of twists and turns to make javac to run out of Stack (even in cases where subtyping can be proved). What does that mean to have such a subtyping test inside the JVM ? That's what I'm worried about. Maurizio From Joe.Darcy at Sun.COM Thu Oct 29 09:20:17 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 29 Oct 2009 09:20:17 -0700 Subject: Reference implementation In-Reply-To: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> Message-ID: <4AE9C0C1.4060306@sun.com> No Howard, your source statement was discussed extensively on this list (see the archives) and it is not a silver bullet and is not going to be part of JDK 7, no matter how many times you bring it up or in how many venues. -Joe Howard Lovatt wrote: > Wouldn't it be simpler to introduce a source statement in Coin, forget the > diamond operator, and get 7 out. Having introduced source, 8 can be > incompatible with previous Java versions (except at the JVM level), > wildcards dropped, generics reified, and type inference for methods and > declarations improved. > > -- Howard. > > ---------- Forwarded message ---------- > From: Maurizio Cimadamore > To: Reinier Zwitserloot > Date: Thu, 29 Oct 2009 15:13:21 +0000 > Subject: Re: Reference implementation > Reinier Zwitserloot wrote: > > >> Actually, those 3 examples don't seem too bad for future expansion. Sure, >> reification is a hard nut to crack, but it always has been. >> >> > Just to clarify - I said that these 3 decisions have made reification > *nearly* impossible - not impossible at all. I guess that the length of your > proposal for dealing with cast speak for itself (if we need to kinda > workaround to the fact that now it's possible to write generic cast even > without reification support that means that the decision does jeopardize > further language evolution - e.g it prevents reified Java from using classic > syntax for casts - note that this problem does not occur with instanceof). > > As far as my other two issues - I'm not concerned about typing and safety - > what I'm concerned about is performances - if you have instances of Foo<#1> > or Foo<#1 extends Object & Comparable > >> are you sure that the VM could still perform decently? The Java subtyping >> > algorithm with generics and wildcards is complex enough that it suffices a > bit of twists and turns to make javac to run out of Stack (even in cases > where subtyping can be proved). What does that mean to have such a subtyping > test inside the JVM ? That's what I'm worried about. > > Maurizio > > From pbenedict at apache.org Thu Oct 29 09:39:07 2009 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 29 Oct 2009 11:39:07 -0500 Subject: Reference implementation In-Reply-To: <4AE9BD12.7050205@sun.com> References: <4AE885B6.2030604@sun.com> <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> <4AE9B6A4.6030007@sun.com> <4AE9BD12.7050205@sun.com> Message-ID: I can't speak for Neal, so he'll have to respond as he sees fit, but I think he doesn't believe the "simple" approach is actually expandable to the "full complex" approach. Am I interpreting correctly? Paul On Thu, Oct 29, 2009 at 11:04 AM, Maurizio Cimadamore wrote: > Paul Benedict wrote: >> >> I think Neal is asking for proof, but the responses given to him are >> in the "I believe" category. Is there some way to prove that the "full >> complex" approach is not cornered out? >> > > What do you exactly mean by cornered out? > > Maurizio >> >> Paul >> >> On Thu, Oct 29, 2009 at 10:37 AM, Maurizio Cimadamore >> wrote: >> >>> >>> Neal Gafter wrote: >>> >>>> >>>> On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore >>>> > >>>> wrote: >>>> >>>> ? Neal, the complex-full approach is essentially your approach plus >>>> ? some magic to make the following work: >>>> >>>> ? Foo = new Foo<>(1); >>>> >>>> ? That is, a complex approach that takes into account the expected >>>> ? return type in order not to infer a type which is too specific. >>>> ? Such an approach would be compatible with the currently >>>> ? implemented simple approach (in fact, ANY other approach that >>>> ? takes into consideration the expected return type would be >>>> ? compatible with the simple approach). >>>> >>>> >>>> Are you telling me that you're confident that such "magic" can be >>>> specified, and implemented, and retrofitted onto the implementation of >>>> generic method invocations and argument contexts, without any deep >>>> issues? >>>> ?If so, I'm satisfied. >>>> >>> >>> I think such an approach does exist - on the other hand if it didn't, it >>> would mean that there is no way (other than the simple approach) to >>> support >>> the use case I mentioned several times in this thread. >>> >>> Maurizio >>> >>> >>> >> >> > > From neal at gafter.com Thu Oct 29 09:50:33 2009 From: neal at gafter.com (Neal Gafter) Date: Thu, 29 Oct 2009 09:50:33 -0700 Subject: Reference implementation In-Reply-To: References: <15e8b9d20910281113w65ad833ax1549753a39897fd7@mail.gmail.com> <4AE8AC7F.5040108@sun.com> <15e8b9d20910281536l3e1fb21enbae5a04ec69a0bee@mail.gmail.com> <4AE964F0.10504@sun.com> <15e8b9d20910290818s3b6eda94o23501acf0db15aa@mail.gmail.com> <4AE9B6A4.6030007@sun.com> <4AE9BD12.7050205@sun.com> Message-ID: <15e8b9d20910290950g25af6609ma3a02bf6ce3ffcfe@mail.gmail.com> On Thu, Oct 29, 2009 at 9:39 AM, Paul Benedict wrote: > I can't speak for Neal, so he'll have to respond as he sees fit, but I > think he doesn't believe the "simple" approach is actually expandable > to the "full complex" approach. Am I interpreting correctly? > It would be more correct to say I don't see how to do it. But if Maurizio would (please) assert that he is confident it would be practical (and compatible), I'd be satisfied. If he doesn't have that confidence, then I'd prefer we settle the issue before committing the simple approach to JDK7. From howard.lovatt at iee.org Fri Oct 30 02:06:36 2009 From: howard.lovatt at iee.org (Howard Lovatt) Date: Fri, 30 Oct 2009 10:06:36 +0100 Subject: Reference implementation In-Reply-To: <4AE9C0C1.4060306@sun.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <4AE9C0C1.4060306@sun.com> Message-ID: <3dd3f56a0910300206v7f33d527u5693065f9d0288f2@mail.gmail.com> Joe, As I recall the discussions on source, for that matter the diamond operator re. more extensive type inference, was that the technical discussion had not reached a consensus, but the discussions ended because the outcome was decreed (presumable by some process within Sun). Your reply, "discussed extensively ...", implies that some form of consensus was reached, which is not my recollection. You, and many others, have more in-depth knowledge of the compiler than I have, undoubtedly. However an in-depth knowledge can be both a blessing and a curse. There are many examples were someone with a wider breadth, but not so in-depth, knowledge can come up with a solution by bringing expertise for other areas. An example of where versioning is very successful is WiFi, over a short time scale we have gone from 802.11a to n. The letters are the version numbers, the protocols are different, but the hardware can run multiple versions because much of the infrastructure is common (RF amplifiers, aerials, etc.). Can you not see the parallels: different versions a to n (Java source versions) and the same underlying hardware (the JVM)? The committees that specify WiFi have the same issues: a formal specification, mass deployment, multiple vendors, etc., and the solution that has proven to work well is versioning. Taking ideas from others and other domains is well established in science in general, e.g. Isaac Newton, in 1676 said, "If I have seen a little further it is by standing on the shoulders of Giants." Perhaps you could consider standing on the shoulders of the WiFi giants. -- Howard. 2009/10/29 Joseph D. Darcy > No Howard, your source statement was discussed extensively on this list > (see the archives) and it is not a silver bullet and is not going to be part > of JDK 7, no matter how many times you bring it up or in how many venues. > > -Joe > > > Howard Lovatt wrote: > >> Wouldn't it be simpler to introduce a source statement in Coin, forget the >> diamond operator, and get 7 out. Having introduced source, 8 can be >> incompatible with previous Java versions (except at the JVM level), >> wildcards dropped, generics reified, and type inference for methods and >> declarations improved. >> >> -- Howard. >> >> ---------- Forwarded message ---------- >> From: Maurizio Cimadamore >> To: Reinier Zwitserloot >> Date: Thu, 29 Oct 2009 15:13:21 +0000 >> Subject: Re: Reference implementation >> Reinier Zwitserloot wrote: >> >> >> >>> Actually, those 3 examples don't seem too bad for future expansion. Sure, >>> reification is a hard nut to crack, but it always has been. >>> >>> >>> >> Just to clarify - I said that these 3 decisions have made reification >> *nearly* impossible - not impossible at all. I guess that the length of >> your >> proposal for dealing with cast speak for itself (if we need to kinda >> workaround to the fact that now it's possible to write generic cast even >> without reification support that means that the decision does jeopardize >> further language evolution - e.g it prevents reified Java from using >> classic >> syntax for casts - note that this problem does not occur with >> instanceof). >> >> As far as my other two issues - I'm not concerned about typing and safety >> - >> what I'm concerned about is performances - if you have instances of >> Foo<#1> >> or Foo<#1 extends Object & Comparable> > >> >> >>> are you sure that the VM could still perform decently? The Java subtyping >>> >>> >> algorithm with generics and wildcards is complex enough that it suffices a >> bit of twists and turns to make javac to run out of Stack (even in cases >> where subtyping can be proved). What does that mean to have such a >> subtyping >> test inside the JVM ? That's what I'm worried about. >> >> Maurizio >> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email______________________________________________________________________ > -- -- Howard. From neal at gafter.com Fri Oct 30 07:48:16 2009 From: neal at gafter.com (Neal Gafter) Date: Fri, 30 Oct 2009 07:48:16 -0700 Subject: Reference implementation In-Reply-To: <3dd3f56a0910300206v7f33d527u5693065f9d0288f2@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <4AE9C0C1.4060306@sun.com> <3dd3f56a0910300206v7f33d527u5693065f9d0288f2@mail.gmail.com> Message-ID: <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> Howard- Let me recap the conclusions as I recall them. Your parallel with WiFi breaks down; your proposal for a source declaration would be an enormous change to the specification; the change would be a tiny benefit (if any). The parallel with WiFi breaks down because software, by its very nature, evolves. While wireless devices are generally fixed once manufactured, any given program is likely to undergo extensive changes over its lifetime. One of the main purposes of changes to the Java language is to make such program evolution easier by providing further facilities for programmers to use. But if a prerequisite to using language features in version 8, for example, requires modifying your source code remove or refactor the use of features that are no longer supported (e.g. wildcards, presuming we come up with an alternative that is migration-compatible), it could become an enormous burden to use any new features in existing code. One might as well give version 8 a new name (e.g. Scala). It is an enormous change because, by moving the version specification into the realm of the language, the language specification must provide a precise meaning to any given value of the version string. That means it must incorporate a full specification for all of the supported versions. In addition, it must specify the meaning of programs composed of a mixture of source file versions. While that kind of specification would be useful today, it is not required as part of the language specification, and it is not provided in the JLS. I can easily imagine that would double the size of the JLS. Clearly, that is far outside the scope of project Coin. Finally, the proposal would only be of the smallest benefit. All of the issues we've been wranging with for each of the proposed language features still has to be addressed. We still have to consider backward compatibility if we want programmers to be able to use these features *in the context of an existing code base*. So adding that enormous work item to project coin would not reduce the amount of work for any of the individual features under consideration. In short, a version declaration is neither a silver bullet, nor a solution to any problem we've been struggling with. Cheers, Neal On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt wrote: > Joe, > > As I recall the discussions on source, for that matter the diamond operator > re. more extensive type inference, was that the technical discussion had > not > reached a consensus, but the discussions ended because the outcome was > decreed (presumable by some process within Sun). Your reply, "discussed > extensively ...", implies that some form of consensus was reached, which is > not my recollection. > > You, and many others, have more in-depth knowledge of the compiler than I > have, undoubtedly. However an in-depth knowledge can be both a blessing and > a curse. There are many examples were someone with a wider breadth, but not > so in-depth, knowledge can come up with a solution by bringing expertise > for > other areas. An example of where versioning is very successful is WiFi, > over > a short time scale we have gone from 802.11a to n. The letters are the > version numbers, the protocols are different, but the hardware can run > multiple versions because much of the infrastructure is common (RF > amplifiers, aerials, etc.). Can you not see the parallels: different > versions a to n (Java source versions) and the same underlying hardware > (the > JVM)? The committees that specify WiFi have the same issues: a formal > specification, mass deployment, multiple vendors, etc., and the solution > that has proven to work well is versioning. > > Taking ideas from others and other domains is well established in science > in > general, e.g. Isaac Newton, in 1676 said, "If I have seen a little further > it is by standing on the shoulders of Giants." Perhaps you could consider > standing on the shoulders of the WiFi giants. > > -- Howard. > > 2009/10/29 Joseph D. Darcy > > > No Howard, your source statement was discussed extensively on this list > > (see the archives) and it is not a silver bullet and is not going to be > part > > of JDK 7, no matter how many times you bring it up or in how many venues. > > > > -Joe > > > > > > Howard Lovatt wrote: > > > >> Wouldn't it be simpler to introduce a source statement in Coin, forget > the > >> diamond operator, and get 7 out. Having introduced source, 8 can be > >> incompatible with previous Java versions (except at the JVM level), > >> wildcards dropped, generics reified, and type inference for methods and > >> declarations improved. > >> > >> -- Howard. > >> > >> ---------- Forwarded message ---------- > >> From: Maurizio Cimadamore > >> To: Reinier Zwitserloot > >> Date: Thu, 29 Oct 2009 15:13:21 +0000 > >> Subject: Re: Reference implementation > >> Reinier Zwitserloot wrote: > >> > >> > >> > >>> Actually, those 3 examples don't seem too bad for future expansion. > Sure, > >>> reification is a hard nut to crack, but it always has been. > >>> > >>> > >>> > >> Just to clarify - I said that these 3 decisions have made reification > >> *nearly* impossible - not impossible at all. I guess that the length of > >> your > >> proposal for dealing with cast speak for itself (if we need to kinda > >> workaround to the fact that now it's possible to write generic cast even > >> without reification support that means that the decision does jeopardize > >> further language evolution - e.g it prevents reified Java from using > >> classic > >> syntax for casts - note that this problem does not occur with > >> instanceof). > >> > >> As far as my other two issues - I'm not concerned about typing and > safety > >> - > >> what I'm concerned about is performances - if you have instances of > >> Foo<#1> > >> or Foo<#1 extends Object & Comparable ... > >> > > >> > >> > >>> are you sure that the VM could still perform decently? The Java > subtyping > >>> > >>> > >> algorithm with generics and wildcards is complex enough that it suffices > a > >> bit of twists and turns to make javac to run out of Stack (even in cases > >> where subtyping can be proved). What does that mean to have such a > >> subtyping > >> test inside the JVM ? That's what I'm worried about. > >> > >> Maurizio > >> > >> > >> > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit > http://www.messagelabs.com/email______________________________________________________________________ > > > > > > -- > -- Howard. > > From lk at teamten.com Fri Oct 30 10:03:26 2009 From: lk at teamten.com (Lawrence Kesteloot) Date: Fri, 30 Oct 2009 10:03:26 -0700 Subject: Reference implementation In-Reply-To: <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <4AE9C0C1.4060306@sun.com> <3dd3f56a0910300206v7f33d527u5693065f9d0288f2@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> Message-ID: <997cab100910301003t2fe50ff5g1bf78558f989b0a3@mail.gmail.com> Howard, Let's say we already had your source statement and my source file has "source 6" at the top. Java 7 is released and everything keeps on working. But now I want to modify that file and add, say, strings in switch. So I change the line to "source 7" and add my switch statement. Is that it? What else do I have to change in that file? I have to carefully look through the list of incompatible changes from 6 to 7 and see if any apply to this file. Programmers won't do this and their code will break, sometimes in subtle ways. Then they'll blame Java, because it's psychologically easier than blaming themselves. My guess is that it would make things worse because it would give language designers license to make all sorts of small incompatible changes. Lawrence On Fri, Oct 30, 2009 at 7:48 AM, Neal Gafter wrote: > Howard- > > Let me recap the conclusions as I recall them. > > Your parallel with WiFi breaks down; your proposal for a source declaration > would be an enormous change to the specification; the change would be a tiny > benefit (if any). > > The parallel with WiFi breaks down because software, by its very nature, > evolves. ?While wireless devices are generally fixed once manufactured, any > given program is likely to undergo extensive changes over its lifetime. ?One > of the main purposes of changes to the Java language is to make such program > evolution easier by providing further facilities for programmers to use. > But if a prerequisite to using language features in version 8, for example, > requires modifying your source code remove or refactor the use of features > that are no longer supported (e.g. wildcards, presuming we come up with an > alternative that is migration-compatible), it could become an enormous > burden to use any new features in existing code. ?One might as well give > version 8 a new name (e.g. Scala). > > It is an enormous change because, by moving the version specification into > the realm of the language, the language specification must provide a precise > meaning to any given value of the version string. ?That means it must > incorporate a full specification for all of the supported versions. ?In > addition, it must specify the meaning of programs composed of a mixture of > source file versions. ?While that kind of specification would be useful > today, it is not required as part of the language specification, and it is > not provided in the JLS. ?I can easily imagine that would double the size of > the JLS. ?Clearly, that is far outside the scope of project Coin. > > Finally, the proposal would only be of the smallest benefit. ?All of the > issues we've been wranging with for each of the proposed language features > still has to be addressed. ?We still have to consider backward compatibility > if we want programmers to be able to use these features *in the context of > an existing code base*. ?So adding that enormous work item to project coin > would not reduce the amount of work for any of the individual features under > consideration. > > In short, a version declaration is neither a silver bullet, nor a solution > to any problem we've been struggling with. > > Cheers, > Neal > > On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt wrote: > >> Joe, >> >> As I recall the discussions on source, for that matter the diamond operator >> re. more extensive type inference, was that the technical discussion had >> not >> reached a consensus, but the discussions ended because the outcome was >> decreed (presumable by some process within Sun). Your reply, "discussed >> extensively ...", implies that some form of consensus was reached, which is >> not my recollection. >> >> You, and many others, have more in-depth knowledge of the compiler than I >> have, undoubtedly. However an in-depth knowledge can be both a blessing and >> a curse. There are many examples were someone with a wider breadth, but not >> so in-depth, knowledge can come up with a solution by bringing expertise >> for >> other areas. An example of where versioning is very successful is WiFi, >> over >> a short time scale we have gone from 802.11a to n. The letters are the >> version numbers, the protocols are different, but the hardware can run >> multiple versions because much of the infrastructure is common (RF >> amplifiers, aerials, etc.). Can you not see the parallels: different >> versions a to n (Java source versions) and the same underlying hardware >> (the >> JVM)? The committees that specify WiFi have the same issues: a formal >> specification, mass deployment, multiple vendors, etc., and the solution >> that has proven to work well is versioning. >> >> Taking ideas from others and other domains is well established in science >> in >> general, e.g. Isaac Newton, in 1676 said, "If I have seen a little further >> it is by standing on the shoulders of Giants." Perhaps you could consider >> standing on the shoulders of the WiFi giants. >> >> ?-- Howard. >> >> 2009/10/29 Joseph D. Darcy >> >> > No Howard, your source statement was discussed extensively on this list >> > (see the archives) and it is not a silver bullet and is not going to be >> part >> > of JDK 7, no matter how many times you bring it up or in how many venues. >> > >> > -Joe >> > >> > >> > Howard Lovatt wrote: >> > >> >> Wouldn't it be simpler to introduce a source statement in Coin, forget >> the >> >> diamond operator, and get 7 out. Having introduced source, 8 can be >> >> incompatible with previous Java versions (except at the JVM level), >> >> wildcards dropped, generics reified, and type inference for methods and >> >> declarations improved. >> >> >> >> ?-- Howard. >> >> >> >> ---------- Forwarded message ---------- >> >> From: Maurizio Cimadamore >> >> To: Reinier Zwitserloot >> >> Date: Thu, 29 Oct 2009 15:13:21 +0000 >> >> Subject: Re: Reference implementation >> >> Reinier Zwitserloot wrote: >> >> >> >> >> >> >> >>> Actually, those 3 examples don't seem too bad for future expansion. >> Sure, >> >>> reification is a hard nut to crack, but it always has been. >> >>> >> >>> >> >>> >> >> Just to clarify - I said that these 3 decisions have made reification >> >> *nearly* impossible - not impossible at all. I guess that the length of >> >> your >> >> proposal for dealing with cast speak for itself (if we need to kinda >> >> workaround to the fact that now it's possible to write generic cast even >> >> without reification support that means that the decision does jeopardize >> >> further language evolution - e.g it prevents reified Java from using >> >> classic >> >> syntax for casts - note that this problem does not occur with >> >> ?instanceof). >> >> >> >> As far as my other two issues - I'm not concerned about typing and >> safety >> >> - >> >> what I'm concerned about is performances - if you have instances of >> >> Foo<#1> >> >> or Foo<#1 extends Object & Comparable> ... >> >> > >> >> >> >> >> >>> are you sure that the VM could still perform decently? The Java >> subtyping >> >>> >> >>> >> >> algorithm with generics and wildcards is complex enough that it suffices >> a >> >> bit of twists and turns to make javac to run out of Stack (even in cases >> >> where subtyping can be proved). What does that mean to have such a >> >> subtyping >> >> test inside the JVM ? That's what I'm worried about. >> >> >> >> Maurizio >> >> >> >> >> >> >> > >> > >> > ______________________________________________________________________ >> > This email has been scanned by the MessageLabs Email Security System. >> > For more information please visit >> http://www.messagelabs.com/email______________________________________________________________________ >> > >> >> >> >> -- >> ?-- Howard. >> >> > > From reinier at zwitserloot.com Fri Oct 30 19:40:50 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 31 Oct 2009 02:40:50 +0000 Subject: Reference implementation In-Reply-To: <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <4AE9C0C1.4060306@sun.com> <3dd3f56a0910300206v7f33d527u5693065f9d0288f2@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> Message-ID: You keep asserting that 'source' is a major feature update, and I keep telling you that you're wrong. I'm forced to keep pointing out that 'source' doesn't have a big impact on the size of the JLS. the notion of source version isn't part of the JLS spec, but that's not a problem. The JLS chapter on the source keyword merely needs to explain its format and how it's context sensitive (as it must appear at the top of the CU, this is easy). It should probably include a footnote on what the source property is generally used for, but it doesn't have to. There's precedent for this of course: Last time I checked, the javadoc tool's documentation isn't part of the JLS, and yet javadoc are things that appear in java source files. It does not even need to define what a compatible java compiler should do in the face of a source keyword. It merely needs to state that a compiler MAY fully support them and compile each file accordingly, but a compiler may also simply refuse to compile the file if its not a version the compiler is aware of. The only added requirement is that a java compiler may not compile a source file without at the very least emitting a warning if the source property isn't something it can deal with. Turning to the pragmatic for a moment: Either the concept of 'source' is obvious to java programmers (which I assert), or, if it isn't, the -source property should be removed from javac for being confusing. I've never heard any complaints, so real world experience indicates Joe Q. Coder can deal with it. Current javacs can already support older versions via the -source parameter, so presumably mixing codebases isn't difficult. If for whatever reason it actually is, the next version can start out by locking down the version the first time it encounters a source statement, and aborting with an error if a different one shows up in the same compile run. Experience will dictate the future fate of mixed compilation: If loads of folks complain about the cool things they could do if only mixed compilation works, it's worth investing some time in, and if not, then not. Real world experience beats guesswork by language designers every time. Complicating migration isn't really a fair argument. Three options: 1. v(X+1) is fully backwards compatible anyway. Consider the versions aliases then, as far as the compiler is concerned. Or, include a tool in the JDK's bin dir that simply updates the version number. By definition, this can't cause problems. 2. v(X+1) is almost but not entirely fully backwards compatible. By definition, then, a new feature has been included that would have been a much bigger deal without the source statement, so if we ever get here, the source statement has already proved its worth its weight in gold. A migrator tool in the JDK bin dir can update a source tree, highlighting (or automatically fixing, even) the rare cases where vX code is no longer legal (or does something different in) v(X+1) code. 3. v(X+1) is not backwards compatible. Presumably v(X+1) is then a major update, akin to v1.5 over v1.4, but making _actual_ breaking changes has still become a much easier proposal, and a migrator is still much easier in this scenario: if a certain code snippet is legal in vX and also legal in vX+1 but has a different meaning, a source migrator without source keywords can't tell if a source file is pre- or post- change, and thus, if you run it twice on the same file, you'd break stuff. That would be bad. The existence of the source keyword has made this big change possible, whatever it is, so clearly it is again worth it. Thus, either (A) the impact is negligible, or (B) it makes possible an update that wouldn't have been possible without it. Examples of how a source keyword + a migrator would have been useful for JDK7: Making module a non-context-sensitive keyword would be trivial: The updater finds any usage of 'module' as an identifier, and tosses back- quotes around them. caveat: Java adds a rule that backquotes indicate identifiers, but given that there are other languages on the JVM that for example accept something like "+" as a valid identifier, this seems like a smart plan anyhow. 'module' as an identifier is pretty rare, so even without the backquotes, a migrator can simply tell you about them. Complaints about 'try' not being an appropriate keyword for ARM would be easier: A new keyword could have been added for it instead. Concerns about simple vs. complex vs. full-complex would be much less urgent: It seems that the cases where they are incompatible are either non-existent, or otherwise quite rare, so a migrator can easily identify where it happens and manually add explicit generics into the diamond operator to fix the problem, without turning someone's source into an unrecognizable mess. You yourself quite rightly consider future language flexibility an important thing to keep in mind. A source keyword is quite a big deal when you take future flexibility into consideration. --Reinier Zwitserloot On 2009/30/10, at 14:48, Neal Gafter wrote: > Howard- > > Let me recap the conclusions as I recall them. > > Your parallel with WiFi breaks down; your proposal for a source > declaration > would be an enormous change to the specification; the change would > be a tiny > benefit (if any). > > The parallel with WiFi breaks down because software, by its very > nature, > evolves. While wireless devices are generally fixed once > manufactured, any > given program is likely to undergo extensive changes over its > lifetime. One > of the main purposes of changes to the Java language is to make such > program > evolution easier by providing further facilities for programmers to > use. > But if a prerequisite to using language features in version 8, for > example, > requires modifying your source code remove or refactor the use of > features > that are no longer supported (e.g. wildcards, presuming we come up > with an > alternative that is migration-compatible), it could become an enormous > burden to use any new features in existing code. One might as well > give > version 8 a new name (e.g. Scala). > > It is an enormous change because, by moving the version > specification into > the realm of the language, the language specification must provide a > precise > meaning to any given value of the version string. That means it must > incorporate a full specification for all of the supported versions. > In > addition, it must specify the meaning of programs composed of a > mixture of > source file versions. While that kind of specification would be > useful > today, it is not required as part of the language specification, and > it is > not provided in the JLS. I can easily imagine that would double the > size of > the JLS. Clearly, that is far outside the scope of project Coin. > > Finally, the proposal would only be of the smallest benefit. All of > the > issues we've been wranging with for each of the proposed language > features > still has to be addressed. We still have to consider backward > compatibility > if we want programmers to be able to use these features *in the > context of > an existing code base*. So adding that enormous work item to > project coin > would not reduce the amount of work for any of the individual > features under > consideration. > > In short, a version declaration is neither a silver bullet, nor a > solution > to any problem we've been struggling with. > > Cheers, > Neal > > On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt > wrote: > >> Joe, >> >> As I recall the discussions on source, for that matter the diamond >> operator >> re. more extensive type inference, was that the technical >> discussion had >> not >> reached a consensus, but the discussions ended because the outcome >> was >> decreed (presumable by some process within Sun). Your reply, >> "discussed >> extensively ...", implies that some form of consensus was reached, >> which is >> not my recollection. >> >> You, and many others, have more in-depth knowledge of the compiler >> than I >> have, undoubtedly. However an in-depth knowledge can be both a >> blessing and >> a curse. There are many examples were someone with a wider breadth, >> but not >> so in-depth, knowledge can come up with a solution by bringing >> expertise >> for >> other areas. An example of where versioning is very successful is >> WiFi, >> over >> a short time scale we have gone from 802.11a to n. The letters are >> the >> version numbers, the protocols are different, but the hardware can >> run >> multiple versions because much of the infrastructure is common (RF >> amplifiers, aerials, etc.). Can you not see the parallels: different >> versions a to n (Java source versions) and the same underlying >> hardware >> (the >> JVM)? The committees that specify WiFi have the same issues: a formal >> specification, mass deployment, multiple vendors, etc., and the >> solution >> that has proven to work well is versioning. >> >> Taking ideas from others and other domains is well established in >> science >> in >> general, e.g. Isaac Newton, in 1676 said, "If I have seen a little >> further >> it is by standing on the shoulders of Giants." Perhaps you could >> consider >> standing on the shoulders of the WiFi giants. >> >> -- Howard. >> >> 2009/10/29 Joseph D. Darcy >> >>> No Howard, your source statement was discussed extensively on this >>> list >>> (see the archives) and it is not a silver bullet and is not going >>> to be >> part >>> of JDK 7, no matter how many times you bring it up or in how many >>> venues. >>> >>> -Joe >>> >>> >>> Howard Lovatt wrote: >>> >>>> Wouldn't it be simpler to introduce a source statement in Coin, >>>> forget >> the >>>> diamond operator, and get 7 out. Having introduced source, 8 can be >>>> incompatible with previous Java versions (except at the JVM level), >>>> wildcards dropped, generics reified, and type inference for >>>> methods and >>>> declarations improved. >>>> >>>> -- Howard. >>>> >>>> ---------- Forwarded message ---------- >>>> From: Maurizio Cimadamore >>>> To: Reinier Zwitserloot >>>> Date: Thu, 29 Oct 2009 15:13:21 +0000 >>>> Subject: Re: Reference implementation >>>> Reinier Zwitserloot wrote: >>>> >>>> >>>> >>>>> Actually, those 3 examples don't seem too bad for future >>>>> expansion. >> Sure, >>>>> reification is a hard nut to crack, but it always has been. >>>>> >>>>> >>>>> >>>> Just to clarify - I said that these 3 decisions have made >>>> reification >>>> *nearly* impossible - not impossible at all. I guess that the >>>> length of >>>> your >>>> proposal for dealing with cast speak for itself (if we need to >>>> kinda >>>> workaround to the fact that now it's possible to write generic >>>> cast even >>>> without reification support that means that the decision does >>>> jeopardize >>>> further language evolution - e.g it prevents reified Java from >>>> using >>>> classic >>>> syntax for casts - note that this problem does not occur with >>>> instanceof). >>>> >>>> As far as my other two issues - I'm not concerned about typing and >> safety >>>> - >>>> what I'm concerned about is performances - if you have instances of >>>> Foo<#1> >>>> or Foo<#1 extends Object & Comparable>>> Comparable < >> ... >>>>> >>>> >>>> >>>>> are you sure that the VM could still perform decently? The Java >> subtyping >>>>> >>>>> >>>> algorithm with generics and wildcards is complex enough that it >>>> suffices >> a >>>> bit of twists and turns to make javac to run out of Stack (even >>>> in cases >>>> where subtyping can be proved). What does that mean to have such a >>>> subtyping >>>> test inside the JVM ? That's what I'm worried about. >>>> >>>> Maurizio >>>> >>>> >>>> >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security >>> System. >>> For more information please visit >> http://www.messagelabs.com/email______________________________________________________________________ >>> >> >> >> >> -- >> -- Howard. >> >> > From neal at gafter.com Sat Oct 31 11:21:32 2009 From: neal at gafter.com (Neal Gafter) Date: Sat, 31 Oct 2009 11:21:32 -0700 Subject: Reference implementation In-Reply-To: References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <4AE9C0C1.4060306@sun.com> <3dd3f56a0910300206v7f33d527u5693065f9d0288f2@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> Message-ID: <15e8b9d20910311121r32c75bb2n8f7ca6ebaf412174@mail.gmail.com> On Fri, Oct 30, 2009 at 7:40 PM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > The JLS chapter on the source keyword merely needs to explain its format > and how it's context sensitive (as it must appear at the top of the CU, this > is easy). It should probably include a footnote on what the source property > is generally used for, but it doesn't have to. > If it is part of the source language and affects the interpretation of the syntax and the meaning of declarations, statements, and expressions of the language, then it is part of the language. If it is part of the language then it must be described precisely in the language specification. > There's precedent for this of course: Last time I checked, the javadoc > tool's documentation isn't part of the JLS, and yet javadoc are things that > appear in java source files. > Javadoc comments are comments in the source language, and this aspect is precisely described in the JLS (3.7). Their contents do not affect the syntax or the meaning of declarations, statements, or expressions of the language. As such, the structure and meaning of their contents needn't be described by the language specification. Cheers, Neal From peter.levart at gmail.com Sat Oct 31 11:24:41 2009 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 31 Oct 2009 19:24:41 +0100 Subject: Reference implementation In-Reply-To: References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> Message-ID: <200910311924.41790.peter.levart@gmail.com> Reinier, Even if compiler would know and work happily (correctly) with a plethora of language variations called "Java" where the same snippet of code would mean different things in different versions, I for certain would be very frustrated to work in such an environment (as I'm no computer). Peter On Saturday 31 October 2009 03:40:50 Reinier Zwitserloot wrote: > You keep asserting that 'source' is a major feature update, and I keep > telling you that you're wrong. I'm forced to keep pointing out that > 'source' doesn't have a big impact on the size of the JLS. > > the notion of source version isn't part of the JLS spec, but that's > not a problem. The JLS chapter on the source keyword merely needs to > explain its format and how it's context sensitive (as it must appear > at the top of the CU, this is easy). It should probably include a > footnote on what the source property is generally used for, but it > doesn't have to. > > There's precedent for this of course: Last time I checked, the javadoc > tool's documentation isn't part of the JLS, and yet javadoc are things > that appear in java source files. > > It does not even need to define what a compatible java compiler should > do in the face of a source keyword. It merely needs to state that a > compiler MAY fully support them and compile each file accordingly, but > a compiler may also simply refuse to compile the file if its not a > version the compiler is aware of. The only added requirement is that a > java compiler may not compile a source file without at the very least > emitting a warning if the source property isn't something it can deal > with. > > Turning to the pragmatic for a moment: > > Either the concept of 'source' is obvious to java programmers (which I > assert), or, if it isn't, the -source property should be removed from > javac for being confusing. I've never heard any complaints, so real > world experience indicates Joe Q. Coder can deal with it. > > Current javacs can already support older versions via the -source > parameter, so presumably mixing codebases isn't difficult. If for > whatever reason it actually is, the next version can start out by > locking down the version the first time it encounters a source > statement, and aborting with an error if a different one shows up in > the same compile run. Experience will dictate the future fate of mixed > compilation: If loads of folks complain about the cool things they > could do if only mixed compilation works, it's worth investing some > time in, and if not, then not. Real world experience beats guesswork > by language designers every time. > > > Complicating migration isn't really a fair argument. Three options: > > 1. v(X+1) is fully backwards compatible anyway. Consider the versions > aliases then, as far as the compiler is concerned. Or, include a tool > in the JDK's bin dir that simply updates the version number. By > definition, this can't cause problems. > > 2. v(X+1) is almost but not entirely fully backwards compatible. By > definition, then, a new feature has been included that would have been > a much bigger deal without the source statement, so if we ever get > here, the source statement has already proved its worth its weight in > gold. A migrator tool in the JDK bin dir can update a source tree, > highlighting (or automatically fixing, even) the rare cases where vX > code is no longer legal (or does something different in) v(X+1) code. > > 3. v(X+1) is not backwards compatible. Presumably v(X+1) is then a > major update, akin to v1.5 over v1.4, but making _actual_ breaking > changes has still become a much easier proposal, and a migrator is > still much easier in this scenario: if a certain code snippet is legal > in vX and also legal in vX+1 but has a different meaning, a source > migrator without source keywords can't tell if a source file is pre- > or post- change, and thus, if you run it twice on the same file, you'd > break stuff. That would be bad. The existence of the source keyword > has made this big change possible, whatever it is, so clearly it is > again worth it. > > > Thus, either (A) the impact is negligible, or (B) it makes possible an > update that wouldn't have been possible without it. > > Examples of how a source keyword + a migrator would have been useful > for JDK7: > > Making module a non-context-sensitive keyword would be trivial: The > updater finds any usage of 'module' as an identifier, and tosses back- > quotes around them. caveat: Java adds a rule that backquotes indicate > identifiers, but given that there are other languages on the JVM that > for example accept something like "+" as a valid identifier, this > seems like a smart plan anyhow. 'module' as an identifier is pretty > rare, so even without the backquotes, a migrator can simply tell you > about them. > > Complaints about 'try' not being an appropriate keyword for ARM would > be easier: A new keyword could have been added for it instead. > > Concerns about simple vs. complex vs. full-complex would be much less > urgent: It seems that the cases where they are incompatible are either > non-existent, or otherwise quite rare, so a migrator can easily > identify where it happens and manually add explicit generics into the > diamond operator to fix the problem, without turning someone's source > into an unrecognizable mess. You yourself quite rightly consider > future language flexibility an important thing to keep in mind. A > source keyword is quite a big deal when you take future flexibility > into consideration. > > > --Reinier Zwitserloot > > On 2009/30/10, at 14:48, Neal Gafter wrote: > > Howard- > > > > Let me recap the conclusions as I recall them. > > > > Your parallel with WiFi breaks down; your proposal for a source > > declaration > > would be an enormous change to the specification; the change would > > be a tiny > > benefit (if any). > > > > The parallel with WiFi breaks down because software, by its very > > nature, > > evolves. While wireless devices are generally fixed once > > manufactured, any > > given program is likely to undergo extensive changes over its > > lifetime. One > > of the main purposes of changes to the Java language is to make such > > program > > evolution easier by providing further facilities for programmers to > > use. > > But if a prerequisite to using language features in version 8, for > > example, > > requires modifying your source code remove or refactor the use of > > features > > that are no longer supported (e.g. wildcards, presuming we come up > > with an > > alternative that is migration-compatible), it could become an enormous > > burden to use any new features in existing code. One might as well > > give > > version 8 a new name (e.g. Scala). > > > > It is an enormous change because, by moving the version > > specification into > > the realm of the language, the language specification must provide a > > precise > > meaning to any given value of the version string. That means it must > > incorporate a full specification for all of the supported versions. > > In > > addition, it must specify the meaning of programs composed of a > > mixture of > > source file versions. While that kind of specification would be > > useful > > today, it is not required as part of the language specification, and > > it is > > not provided in the JLS. I can easily imagine that would double the > > size of > > the JLS. Clearly, that is far outside the scope of project Coin. > > > > Finally, the proposal would only be of the smallest benefit. All of > > the > > issues we've been wranging with for each of the proposed language > > features > > still has to be addressed. We still have to consider backward > > compatibility > > if we want programmers to be able to use these features *in the > > context of > > an existing code base*. So adding that enormous work item to > > project coin > > would not reduce the amount of work for any of the individual > > features under > > consideration. > > > > In short, a version declaration is neither a silver bullet, nor a > > solution > > to any problem we've been struggling with. > > > > Cheers, > > Neal > > > > On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt > > > > wrote: > >> Joe, > >> > >> As I recall the discussions on source, for that matter the diamond > >> operator > >> re. more extensive type inference, was that the technical > >> discussion had > >> not > >> reached a consensus, but the discussions ended because the outcome > >> was > >> decreed (presumable by some process within Sun). Your reply, > >> "discussed > >> extensively ...", implies that some form of consensus was reached, > >> which is > >> not my recollection. > >> > >> You, and many others, have more in-depth knowledge of the compiler > >> than I > >> have, undoubtedly. However an in-depth knowledge can be both a > >> blessing and > >> a curse. There are many examples were someone with a wider breadth, > >> but not > >> so in-depth, knowledge can come up with a solution by bringing > >> expertise > >> for > >> other areas. An example of where versioning is very successful is > >> WiFi, > >> over > >> a short time scale we have gone from 802.11a to n. The letters are > >> the > >> version numbers, the protocols are different, but the hardware can > >> run > >> multiple versions because much of the infrastructure is common (RF > >> amplifiers, aerials, etc.). Can you not see the parallels: different > >> versions a to n (Java source versions) and the same underlying > >> hardware > >> (the > >> JVM)? The committees that specify WiFi have the same issues: a formal > >> specification, mass deployment, multiple vendors, etc., and the > >> solution > >> that has proven to work well is versioning. > >> > >> Taking ideas from others and other domains is well established in > >> science > >> in > >> general, e.g. Isaac Newton, in 1676 said, "If I have seen a little > >> further > >> it is by standing on the shoulders of Giants." Perhaps you could > >> consider > >> standing on the shoulders of the WiFi giants. > >> > >> -- Howard. > >> > >> 2009/10/29 Joseph D. Darcy > >> > >>> No Howard, your source statement was discussed extensively on this > >>> list > >>> (see the archives) and it is not a silver bullet and is not going > >>> to be > >> > >> part > >> > >>> of JDK 7, no matter how many times you bring it up or in how many > >>> venues. > >>> > >>> -Joe > >>> > >>> Howard Lovatt wrote: > >>>> Wouldn't it be simpler to introduce a source statement in Coin, > >>>> forget > >> > >> the > >> > >>>> diamond operator, and get 7 out. Having introduced source, 8 can be > >>>> incompatible with previous Java versions (except at the JVM level), > >>>> wildcards dropped, generics reified, and type inference for > >>>> methods and > >>>> declarations improved. > >>>> > >>>> -- Howard. > >>>> > >>>> ---------- Forwarded message ---------- > >>>> From: Maurizio Cimadamore > >>>> To: Reinier Zwitserloot > >>>> Date: Thu, 29 Oct 2009 15:13:21 +0000 > >>>> Subject: Re: Reference implementation > >>>> > >>>> Reinier Zwitserloot wrote: > >>>>> Actually, those 3 examples don't seem too bad for future > >>>>> expansion. > >> > >> Sure, > >> > >>>>> reification is a hard nut to crack, but it always has been. > >>>> > >>>> Just to clarify - I said that these 3 decisions have made > >>>> reification > >>>> *nearly* impossible - not impossible at all. I guess that the > >>>> length of > >>>> your > >>>> proposal for dealing with cast speak for itself (if we need to > >>>> kinda > >>>> workaround to the fact that now it's possible to write generic > >>>> cast even > >>>> without reification support that means that the decision does > >>>> jeopardize > >>>> further language evolution - e.g it prevents reified Java from > >>>> using > >>>> classic > >>>> syntax for casts - note that this problem does not occur with > >>>> instanceof). > >>>> > >>>> As far as my other two issues - I'm not concerned about typing and > >> > >> safety > >> > >>>> - > >>>> what I'm concerned about is performances - if you have instances of > >>>> Foo<#1> > >>>> or Foo<#1 extends Object & Comparable >>>> Comparable < > >> > >> ... > >> > >>>>> are you sure that the VM could still perform decently? The Java > >> > >> subtyping > >> > >>>> algorithm with generics and wildcards is complex enough that it > >>>> suffices > >> > >> a > >> > >>>> bit of twists and turns to make javac to run out of Stack (even > >>>> in cases > >>>> where subtyping can be proved). What does that mean to have such a > >>>> subtyping > >>>> test inside the JVM ? That's what I'm worried about. > >>>> > >>>> Maurizio > >>> > >>> ______________________________________________________________________ > >>> This email has been scanned by the MessageLabs Email Security > >>> System. > >>> For more information please visit > >> > >> http://www.messagelabs.com/email________________________________________ > >>______________________________ > >> > >> > >> > >> > >> -- > >> -- Howard. > From reinier at zwitserloot.com Sat Oct 31 12:43:44 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 31 Oct 2009 19:43:44 +0000 Subject: Reference implementation In-Reply-To: <200910311924.41790.peter.levart@gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> <200910311924.41790.peter.levart@gmail.com> Message-ID: <560fb5ed0910311243y31a76107m7c2f8291f4dde5e5@mail.gmail.com> Peter: And yet you use java every day, where this happens all the time. Just 6 months ago I was hacking around on some pre-generics code, for example. Your argument is spanning the cart in front of the horse: "Language evolution is complex, so if we close our eyes and stick our fingers in our ears, maybe it'll go away!" - language evolution is there. Yes, it's complicated, but we have to deal with it. A source statement helps up deal with it a little better. Yes, it also makes the concept more _visible_, but it's always been there. The fact that the JLS ignores the concept of evolution is a BAD thing, not a good thing. Neal: as I mentioned, the source statement may not have any effect, other than generating a warning or 'not compatible with this version' error. For the smarter compilers that know how to deal with it, it's the compiler that decides to use a different version of the JLS when compiling the source file - not a dictate written in the JLS. I don't understand why you see such an enormous difference between "javac -source 1.4 MyFile.java" and "javac MyFile.java" with a "source 1.4;" at the top of the file - it's a small semantic difference that is useful all around. Getting hung up on some theoretical purity-of-the-spec argument seems rather silly, given that pragmatically speaking there's no problem whatsoever. Lots and lots of languages allow you to change compiler flags via magic comments. This is just that, except without using "//" syntax. --Reinier Zwitserloot On Sat, Oct 31, 2009 at 6:24 PM, Peter Levart wrote: > Reinier, > > Even if compiler would know and work happily (correctly) with a plethora of > language variations > called "Java" where the same snippet of code would mean different things in > different versions, I > for certain would be very frustrated to work in such an environment (as I'm > no computer). > > Peter > > On Saturday 31 October 2009 03:40:50 Reinier Zwitserloot wrote: > > You keep asserting that 'source' is a major feature update, and I keep > > telling you that you're wrong. I'm forced to keep pointing out that > > 'source' doesn't have a big impact on the size of the JLS. > > > > the notion of source version isn't part of the JLS spec, but that's > > not a problem. The JLS chapter on the source keyword merely needs to > > explain its format and how it's context sensitive (as it must appear > > at the top of the CU, this is easy). It should probably include a > > footnote on what the source property is generally used for, but it > > doesn't have to. > > > > There's precedent for this of course: Last time I checked, the javadoc > > tool's documentation isn't part of the JLS, and yet javadoc are things > > that appear in java source files. > > > > It does not even need to define what a compatible java compiler should > > do in the face of a source keyword. It merely needs to state that a > > compiler MAY fully support them and compile each file accordingly, but > > a compiler may also simply refuse to compile the file if its not a > > version the compiler is aware of. The only added requirement is that a > > java compiler may not compile a source file without at the very least > > emitting a warning if the source property isn't something it can deal > > with. > > > > Turning to the pragmatic for a moment: > > > > Either the concept of 'source' is obvious to java programmers (which I > > assert), or, if it isn't, the -source property should be removed from > > javac for being confusing. I've never heard any complaints, so real > > world experience indicates Joe Q. Coder can deal with it. > > > > Current javacs can already support older versions via the -source > > parameter, so presumably mixing codebases isn't difficult. If for > > whatever reason it actually is, the next version can start out by > > locking down the version the first time it encounters a source > > statement, and aborting with an error if a different one shows up in > > the same compile run. Experience will dictate the future fate of mixed > > compilation: If loads of folks complain about the cool things they > > could do if only mixed compilation works, it's worth investing some > > time in, and if not, then not. Real world experience beats guesswork > > by language designers every time. > > > > > > Complicating migration isn't really a fair argument. Three options: > > > > 1. v(X+1) is fully backwards compatible anyway. Consider the versions > > aliases then, as far as the compiler is concerned. Or, include a tool > > in the JDK's bin dir that simply updates the version number. By > > definition, this can't cause problems. > > > > 2. v(X+1) is almost but not entirely fully backwards compatible. By > > definition, then, a new feature has been included that would have been > > a much bigger deal without the source statement, so if we ever get > > here, the source statement has already proved its worth its weight in > > gold. A migrator tool in the JDK bin dir can update a source tree, > > highlighting (or automatically fixing, even) the rare cases where vX > > code is no longer legal (or does something different in) v(X+1) code. > > > > 3. v(X+1) is not backwards compatible. Presumably v(X+1) is then a > > major update, akin to v1.5 over v1.4, but making _actual_ breaking > > changes has still become a much easier proposal, and a migrator is > > still much easier in this scenario: if a certain code snippet is legal > > in vX and also legal in vX+1 but has a different meaning, a source > > migrator without source keywords can't tell if a source file is pre- > > or post- change, and thus, if you run it twice on the same file, you'd > > break stuff. That would be bad. The existence of the source keyword > > has made this big change possible, whatever it is, so clearly it is > > again worth it. > > > > > > Thus, either (A) the impact is negligible, or (B) it makes possible an > > update that wouldn't have been possible without it. > > > > Examples of how a source keyword + a migrator would have been useful > > for JDK7: > > > > Making module a non-context-sensitive keyword would be trivial: The > > updater finds any usage of 'module' as an identifier, and tosses back- > > quotes around them. caveat: Java adds a rule that backquotes indicate > > identifiers, but given that there are other languages on the JVM that > > for example accept something like "+" as a valid identifier, this > > seems like a smart plan anyhow. 'module' as an identifier is pretty > > rare, so even without the backquotes, a migrator can simply tell you > > about them. > > > > Complaints about 'try' not being an appropriate keyword for ARM would > > be easier: A new keyword could have been added for it instead. > > > > Concerns about simple vs. complex vs. full-complex would be much less > > urgent: It seems that the cases where they are incompatible are either > > non-existent, or otherwise quite rare, so a migrator can easily > > identify where it happens and manually add explicit generics into the > > diamond operator to fix the problem, without turning someone's source > > into an unrecognizable mess. You yourself quite rightly consider > > future language flexibility an important thing to keep in mind. A > > source keyword is quite a big deal when you take future flexibility > > into consideration. > > > > > > --Reinier Zwitserloot > > > > On 2009/30/10, at 14:48, Neal Gafter wrote: > > > Howard- > > > > > > Let me recap the conclusions as I recall them. > > > > > > Your parallel with WiFi breaks down; your proposal for a source > > > declaration > > > would be an enormous change to the specification; the change would > > > be a tiny > > > benefit (if any). > > > > > > The parallel with WiFi breaks down because software, by its very > > > nature, > > > evolves. While wireless devices are generally fixed once > > > manufactured, any > > > given program is likely to undergo extensive changes over its > > > lifetime. One > > > of the main purposes of changes to the Java language is to make such > > > program > > > evolution easier by providing further facilities for programmers to > > > use. > > > But if a prerequisite to using language features in version 8, for > > > example, > > > requires modifying your source code remove or refactor the use of > > > features > > > that are no longer supported (e.g. wildcards, presuming we come up > > > with an > > > alternative that is migration-compatible), it could become an enormous > > > burden to use any new features in existing code. One might as well > > > give > > > version 8 a new name (e.g. Scala). > > > > > > It is an enormous change because, by moving the version > > > specification into > > > the realm of the language, the language specification must provide a > > > precise > > > meaning to any given value of the version string. That means it must > > > incorporate a full specification for all of the supported versions. > > > In > > > addition, it must specify the meaning of programs composed of a > > > mixture of > > > source file versions. While that kind of specification would be > > > useful > > > today, it is not required as part of the language specification, and > > > it is > > > not provided in the JLS. I can easily imagine that would double the > > > size of > > > the JLS. Clearly, that is far outside the scope of project Coin. > > > > > > Finally, the proposal would only be of the smallest benefit. All of > > > the > > > issues we've been wranging with for each of the proposed language > > > features > > > still has to be addressed. We still have to consider backward > > > compatibility > > > if we want programmers to be able to use these features *in the > > > context of > > > an existing code base*. So adding that enormous work item to > > > project coin > > > would not reduce the amount of work for any of the individual > > > features under > > > consideration. > > > > > > In short, a version declaration is neither a silver bullet, nor a > > > solution > > > to any problem we've been struggling with. > > > > > > Cheers, > > > Neal > > > > > > On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt > > > > > > wrote: > > >> Joe, > > >> > > >> As I recall the discussions on source, for that matter the diamond > > >> operator > > >> re. more extensive type inference, was that the technical > > >> discussion had > > >> not > > >> reached a consensus, but the discussions ended because the outcome > > >> was > > >> decreed (presumable by some process within Sun). Your reply, > > >> "discussed > > >> extensively ...", implies that some form of consensus was reached, > > >> which is > > >> not my recollection. > > >> > > >> You, and many others, have more in-depth knowledge of the compiler > > >> than I > > >> have, undoubtedly. However an in-depth knowledge can be both a > > >> blessing and > > >> a curse. There are many examples were someone with a wider breadth, > > >> but not > > >> so in-depth, knowledge can come up with a solution by bringing > > >> expertise > > >> for > > >> other areas. An example of where versioning is very successful is > > >> WiFi, > > >> over > > >> a short time scale we have gone from 802.11a to n. The letters are > > >> the > > >> version numbers, the protocols are different, but the hardware can > > >> run > > >> multiple versions because much of the infrastructure is common (RF > > >> amplifiers, aerials, etc.). Can you not see the parallels: different > > >> versions a to n (Java source versions) and the same underlying > > >> hardware > > >> (the > > >> JVM)? The committees that specify WiFi have the same issues: a formal > > >> specification, mass deployment, multiple vendors, etc., and the > > >> solution > > >> that has proven to work well is versioning. > > >> > > >> Taking ideas from others and other domains is well established in > > >> science > > >> in > > >> general, e.g. Isaac Newton, in 1676 said, "If I have seen a little > > >> further > > >> it is by standing on the shoulders of Giants." Perhaps you could > > >> consider > > >> standing on the shoulders of the WiFi giants. > > >> > > >> -- Howard. > > >> > > >> 2009/10/29 Joseph D. Darcy > > >> > > >>> No Howard, your source statement was discussed extensively on this > > >>> list > > >>> (see the archives) and it is not a silver bullet and is not going > > >>> to be > > >> > > >> part > > >> > > >>> of JDK 7, no matter how many times you bring it up or in how many > > >>> venues. > > >>> > > >>> -Joe > > >>> > > >>> Howard Lovatt wrote: > > >>>> Wouldn't it be simpler to introduce a source statement in Coin, > > >>>> forget > > >> > > >> the > > >> > > >>>> diamond operator, and get 7 out. Having introduced source, 8 can be > > >>>> incompatible with previous Java versions (except at the JVM level), > > >>>> wildcards dropped, generics reified, and type inference for > > >>>> methods and > > >>>> declarations improved. > > >>>> > > >>>> -- Howard. > > >>>> > > >>>> ---------- Forwarded message ---------- > > >>>> From: Maurizio Cimadamore > > >>>> To: Reinier Zwitserloot > > >>>> Date: Thu, 29 Oct 2009 15:13:21 +0000 > > >>>> Subject: Re: Reference implementation > > >>>> > > >>>> Reinier Zwitserloot wrote: > > >>>>> Actually, those 3 examples don't seem too bad for future > > >>>>> expansion. > > >> > > >> Sure, > > >> > > >>>>> reification is a hard nut to crack, but it always has been. > > >>>> > > >>>> Just to clarify - I said that these 3 decisions have made > > >>>> reification > > >>>> *nearly* impossible - not impossible at all. I guess that the > > >>>> length of > > >>>> your > > >>>> proposal for dealing with cast speak for itself (if we need to > > >>>> kinda > > >>>> workaround to the fact that now it's possible to write generic > > >>>> cast even > > >>>> without reification support that means that the decision does > > >>>> jeopardize > > >>>> further language evolution - e.g it prevents reified Java from > > >>>> using > > >>>> classic > > >>>> syntax for casts - note that this problem does not occur with > > >>>> instanceof). > > >>>> > > >>>> As far as my other two issues - I'm not concerned about typing and > > >> > > >> safety > > >> > > >>>> - > > >>>> what I'm concerned about is performances - if you have instances of > > >>>> Foo<#1> > > >>>> or Foo<#1 extends Object & Comparable > >>>> Comparable < > > >> > > >> ... > > >> > > >>>>> are you sure that the VM could still perform decently? The Java > > >> > > >> subtyping > > >> > > >>>> algorithm with generics and wildcards is complex enough that it > > >>>> suffices > > >> > > >> a > > >> > > >>>> bit of twists and turns to make javac to run out of Stack (even > > >>>> in cases > > >>>> where subtyping can be proved). What does that mean to have such a > > >>>> subtyping > > >>>> test inside the JVM ? That's what I'm worried about. > > >>>> > > >>>> Maurizio > > >>> > > >>> > ______________________________________________________________________ > > >>> This email has been scanned by the MessageLabs Email Security > > >>> System. > > >>> For more information please visit > > >> > > >> > http://www.messagelabs.com/email________________________________________ > > >>______________________________ > > >> > > >> > > >> > > >> > > >> -- > > >> -- Howard. > > > From neal at gafter.com Sat Oct 31 17:20:57 2009 From: neal at gafter.com (Neal Gafter) Date: Sat, 31 Oct 2009 17:20:57 -0700 Subject: Reference implementation In-Reply-To: <560fb5ed0910311243y31a76107m7c2f8291f4dde5e5@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> <200910311924.41790.peter.levart@gmail.com> <560fb5ed0910311243y31a76107m7c2f8291f4dde5e5@mail.gmail.com> Message-ID: <15e8b9d20910311720l78705e5bs60a1dfffb87c45c2@mail.gmail.com> On Sat, Oct 31, 2009 at 12:43 PM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > Neal: as I mentioned, the source statement may not have any effect, other > than generating a warning or 'not compatible with this version' error. For > the smarter compilers that know how to deal with it, it's the compiler that > decides to use a different version of the JLS when compiling the source > file > - not a dictate written in the JLS. The language should not be based on "whatever the compiler understands", but rather vice versa: the compiler should be made to understand what is described in the language specification. Some languages - for example, Groovy and Ruby - take the opposite approach, and that is fine for them. But Java has always taken a strong position that there should be one language that does not vary from implementation to implementation. Sun licenses the Java trademark in a way that enforces that unity, and I would not advocate changing that. From reinier at zwitserloot.com Sat Oct 31 20:09:30 2009 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sun, 1 Nov 2009 03:09:30 +0000 Subject: Reference implementation In-Reply-To: <15e8b9d20910311720l78705e5bs60a1dfffb87c45c2@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> <200910311924.41790.peter.levart@gmail.com> <560fb5ed0910311243y31a76107m7c2f8291f4dde5e5@mail.gmail.com> <15e8b9d20910311720l78705e5bs60a1dfffb87c45c2@mail.gmail.com> Message-ID: <560fb5ed0910312009m3b514bcy2984c5f083e597d2@mail.gmail.com> How does not encoding what the source statement does mess with this? Any given source file will compile the exact same way given a compiler that is both java certified and compatible with the version you're using. That's true now. That'll be true with a source statement as well. So, how is the status quo any different? If I take a certified, sun-stamp-of-approval-carrying jikes from the stone age and try to compile my shiny new for eaches in it, it'll fail to compile my code. --Reinier Zwitserloot On Sun, Nov 1, 2009 at 12:20 AM, Neal Gafter wrote: > On Sat, Oct 31, 2009 at 12:43 PM, Reinier Zwitserloot < > reinier at zwitserloot.com> wrote: > >> Neal: as I mentioned, the source statement may not have any effect, other >> than generating a warning or 'not compatible with this version' error. For >> the smarter compilers that know how to deal with it, it's the compiler >> that >> decides to use a different version of the JLS when compiling the source >> file >> - not a dictate written in the JLS. > > > The language should not be based on "whatever the compiler understands", > but rather vice versa: the compiler should be made to understand what is > described in the language specification. Some languages - for example, > Groovy and Ruby - take the opposite approach, and that is fine for them. > But Java has always taken a strong position that there should be one > language that does not vary from implementation to implementation. Sun > licenses the Java trademark in a way that enforces that unity, and I would > not advocate changing that. > From neal at gafter.com Sat Oct 31 23:59:22 2009 From: neal at gafter.com (Neal Gafter) Date: Sat, 31 Oct 2009 23:59:22 -0700 Subject: Reference implementation In-Reply-To: <560fb5ed0910312009m3b514bcy2984c5f083e597d2@mail.gmail.com> References: <3dd3f56a0910290904m3a70673dn5dee12eec55a776@mail.gmail.com> <15e8b9d20910300748l4322aca0i379763b15816745@mail.gmail.com> <200910311924.41790.peter.levart@gmail.com> <560fb5ed0910311243y31a76107m7c2f8291f4dde5e5@mail.gmail.com> <15e8b9d20910311720l78705e5bs60a1dfffb87c45c2@mail.gmail.com> <560fb5ed0910312009m3b514bcy2984c5f083e597d2@mail.gmail.com> Message-ID: <15e8b9d20910312359n5c842e1av9179325756ca94c6@mail.gmail.com> On Sat, Oct 31, 2009 at 8:09 PM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > Any given source file will compile the exact same way given a compiler that > is both java certified and compatible with the version you're using. That's > true now. That'll be true with a source statement as well. > > So, how is the status quo any different? If I take a certified, > sun-stamp-of-approval-carrying jikes from the stone age and try to compile > my shiny new for eaches in it, it'll fail to compile my code. > Well, that conflicts with your goal of having the ability to 1. Instead of being forced to move your entire source base over, you can just go one file at a time, swapping from source 6 to source 7 as you edit the files and need to use new features. Your project recompile will just print whatever incompatibilities arose from changing that one file over; Fixing these by hand should be a trivial job. Your certified sun-stamp-of-approval-carrying compiler will accept only a single source version in a single compilation, corresponding to one particular Java SE platform specification. A compiler that does otherwise would violate the TCK conformance rules. It appears that we're talking at cross purposes. Fortunately, the point is moot, as this feature has not been accepted for Java SE 7, nor specified at the necessary level of detail, nor implemented in time to be integrated into the openjdk7 feature-complete milestone. I'll be happy to discuss it with you further next time we're in the same area, perhaps over a beer. Cheers, Neal