Loose end: zip

[Joe Bowbeer]

Those arguments against Pair are pretty old, and sound a lot like the
arguments against fleshing-out Optional (reflecting the current state of
Guava).

*Not* requiring functional programmers to create their own types at every
opportunity facilitates fluent programming.

Pair already exists in Java in the form of Map.Entry.  Having Map.Entry
extend Pair would be my approach, btw.

Joe


On Sat, Jun 8, 2013 at 11:00 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Yeah, I'm not surprised.  Zip is an idiom that is built on the assumption
> of tuples.
>
> "To Pair or Not To Pair" is well covered ground; every time it has come
> up, the consensus has been "more harm than good."  For example:
>
>
> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2010-**
> March/003994.html<http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003994.html>
>
> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2010-**
> March/003997.html<http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003997.html>
>
>
>
>
> On 6/9/2013 12:40 AM, Joe Bowbeer wrote:
>
>> I have not used this zip, actually, and I just tried to use it and I was
>> not pleased.
>>
>> When I use zip, I'm usually pairing keys to items.  Usually the keys are
>> ints and the items are some app-specific object, or maybe just a string:
>>
>> zipped = zip(ints(), collection.stream());
>>
>> *This* version of zip requires me to supply a third "zipper" argument,
>> which means I also have to make up a type for the pairs.
>>
>> What I really want is a zip that returns Stream<Pair<A,B>> so I don't
>> have to deal with the pairing:
>>
>> <A,B> Stream<Pair<A,B>> zip(Stream<? extends A> a, Stream<? extends B> b)
>>
>> --Joe
>>
>>
>> On Thu, Jun 6, 2013 at 4:53 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com**>> wrote:
>>
>>     Has anyone on the EG experimented with *this* version of zip?  Do
>>     you have experience to report?
>>
>>
>>     On 6/6/2013 6:58 PM, Joe Bowbeer wrote:
>>
>>         I don't think I have anything to add to what I already said: zip
>>         is an
>>         expressive, useful tool.
>>
>>         Java programmers effectively use maps of maps, and maps of
>>         lists, and
>>         lists of maps, and all kinds of inefficient things.
>>
>>         Originally, Java's biggest advantage was its increased
>> productivity.
>>            That one advantage can make up for lots of little
>>         disappointments.
>>
>>         I definitely don't want to have to search for a zip snippet
>>         somewhere
>>         (e.g., in Fugue?).  A basic tool like zip is not something I
>>         would look
>>         for in an extension library.
>>
>>         Regarding the no-primitive versions, I think the consensus was
>>         to live
>>         with that.
>>
>>
>>         On Thu, Jun 6, 2013 at 12:49 PM, Brian Goetz
>>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com**>
>>         <mailto:brian.goetz at oracle.com
>>
>>         <mailto:brian.goetz at oracle.com**>__>> wrote:
>>
>>              Still feeling kind of YAGNI on zip, for the reasons cited
>>         in the
>>              message below, plus:
>>                - No primitive versions (would require new SAMs)
>>                - Hard to parallelize
>>                - Multiple ways to deal with streams of different length;
>>         we pick one
>>
>>              Might this be something best provided by some other library
>>         than the
>>              JDK?  Or as a code example somewhere people can crib from
>>         to roll
>>              their own?
>>
>>              On 5/1/2013 5:10 PM, Brian Goetz wrote:
>>
>>                  Right, but the question is, how badly can we implement
>>         it and
>>                  have it
>>                  not be worse than nothing?  And, with the current
>>         performance
>>                  characteristics (new object per element), are we below
>> that
>>                  threshold?
>>
>>                  My problem is the same as with flatMap -- these are
>>         idioms from
>>                  other
>>                  languages that *translate poorly* to Java because of
>>         the lack of
>>                  tuples
>>                  and other structural types.  (The flatMap we got left
>>         with --
>>                  which I
>>                  reluctantly supported as the lesser of evils -- is,
>>                  coincidentally, the
>>                  only other stream operation that has
>>         allocation-per-element.)
>>                    At what
>>                  level of translation-fidelity loss do we say "yeah, it
>>         works
>>                  great in
>>                  that other environment, but too much is lost in
>>         translation"?
>>
>>                  I don't doubt the utility of zip, or the fact that
>>         Joe-alikes
>>                  will want
>>                  it, and would be bummed to not find it.  My question is
>>         whether the
>>                  crappy zip we can have is better than no zip.  (Where
>>         better doesn't
>>                  just mean "better than nothing", but carries its weight.)
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130608/5d8b5e0c/attachment-0001.html