Loose end: zip
joe.bowbeer at gmail.com
Sat Jun 8 21:40:31 PDT 2013
I have not used this zip, actually, and I just tried to use it and I was
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)
On Thu, Jun 6, 2013 at 4:53 PM, Brian Goetz <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**>> 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
>> 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
>> My problem is the same as with flatMap -- these are idioms from
>> languages that *translate poorly* to Java because of the lack of
>> 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
>> crappy zip we can have is better than no zip. (Where better
>> just mean "better than nothing", but carries its weight.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts