Loose end: zip

[Brian Goetz]

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 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.)
>
>