JEP 186: Collection Literals

[Zhong Yu]

On Wed, Jan 22, 2014 at 6:57 AM, Roel Spilker <r.spilker at gmail.com> wrote:
> I am not attached to any implementation, let alone have a full feature
> proposal. I'm only sharing my experience that there is an area where value
> types are being used where the actual type is not really relevant. And I'm
> suggesting that this topic might be part of the design space.
>
> Now that that's out of the way let's respond to your concerns:
> - I do understand that any change to the type system complicates overload
> resolution etc. However, moving the burden from the java developer to the
> compiler developer is what removing boiler plate is all about.
> - Any tuple design would have have to address similar concerns.
> - To answer your last question: in regular code you wouldn't be able to
> assign the (tuple/single) result. And for reflection you could have a
> separate API.
> - I really don't like a general purpose Pair class with a second() method.
> Than I'd rather have (cheap) value types so I can at least name the values,
> and give them proper documentation.

I agree here. A generic tuple, with generic component names,
does not express the intent of the code very well.

>
>
> On Wed, Jan 22, 2014 at 4:17 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> On Tue, Jan 21, 2014 at 4:59 PM, Roel Spilker <r.spilker at gmail.com> wrote:
>> > As a Lombok developer I have quite some experience with value types. I
>> > do
>> > think value types are very important.
>> >
>> > That said, I notice that most of them are used to return two or more
>> > values
>> > from a method. In concurrent programming this is even more important.
>> > The
>> > current workaround in AtomicMarkableReference and AtomicStampedReference
>> > is
>> > to return one value and put the other value in the array that was passed
>> > as
>> > a parameter.
>> >
>> > There is a way to have multiple return values without introducing new
>> > types
>> > (at least for the java programmer). At the risk of getting into a syntax
>> > discussion, one possible way would be to only allow the results to be
>> > assigned to fields, local variables or parameters directly. Example:
>>
>> This proposal is going to complicate overload resolution, type
>> inference, override equivalency check, etc, which are already very
>> complicated.
>>
>> It breaks a very basic assumption that a method returns a type; for
>> example, what `java.lang.reflect.Method.getReturnType()` should do
>> now?
>>
>> And the limitation on referencing the return value(s) is quite
>> inconvenient, for example, how do we project the returned tuple to the
>> 2nd element? If foo() returns Pair<int, String> instead, we could do
>> `foo().second()`.
>>
>> Zhong Yu
>>
>> >
>> > public {int, String} foo() {
>> >   return {1, "foo"};
>> > }
>> >
>> > void printFoo() {
>> >   {int count, String message} = foo();
>> >   for (int i = 0; i < count, i++) System.out.println(message);
>> >
>> >   // call a method using the multiple results
>> >   String repeated = repeat(foo(), false);
>> > }
>> >
>> > String repeat(int count, String message, boolean newLines) {
>> >   String result = "";
>> >   for (int i = 0; i < count, i++) {
>> >     result += message;
>> >     if (newLines) result += "\n";
>> > }
>> >
>> > Would having multiple return values be part of the design space?
>> >
>> >
>> > On Tue, Jan 21, 2014 at 8:39 PM, Brian Goetz <brian.goetz at oracle.com>
>> > wrote:
>> >
>> >> So, there's been some good discussion regarding the proper scope of
>> >> Collection Literals, so let me summarize what I heard.  I am sensing
>> >> that the center of gravity is roughly behind these points:
>> >>
>> >> 1.  A "collection literals" feature that only worked for the built-in
>> >> types (e.g., List, Set, Map), but was not extensible to user-defined
>> >> types, would be disappointing.
>> >>
>> >> 2.  Having these literals be mutable would be surprising.
>> >>
>> >> 3.  The real pain is in Maps, not Lists, Sets, or Arrays.
>> >> Library-based
>> >> solutions would be mostly acceptable for the latter, but we still lack
>> >> a
>> >> reasonable way to describe pair literals, which is what's in the way of
>> >> a library-based solution for Map (other than a MapBuilder.)  Static
>> >> methods in interfaces make a library-based solution more practical.
>> >> With value types, though, library-based solutions for Map become far
>> >> more practical too.
>> >>
>> >> 4.  This feature is less critical that many other features, such as
>> >> value types, tuples, or primitive specialization of generics.  For the
>> >> most part, this feature is a nice-to-have, but no one would vote for
>> >> delaying value types because of it.
>> >>
>> >> 5.  The underlying mechanics (varargs at the language level; lack of
>> >> constant pool support for arrays at the bytecode level; ad-hoc support
>> >> for caching of (and GC'ing under memory pressure) intermediate
>> >> immutable
>> >> results) remain a limiting factor, even with syntactic sugar.  Working
>> >> on these foundational issues might provide more bang-for-buck.
>> >>
>> >> Of course, in a community of 10M, there will be some range of opinion,
>> >> but the goal of posting this here was to sanity-check our assumptions
>> >> about priorities.  Thanks to all who provided feedback!
>> >>
>> >>
>> >
>
>