Loose end: zip
brian.goetz at oracle.com
Thu Jun 6 16:53:15 PDT 2013
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
> 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 the
> crappy zip we can have is better than no zip. (Where better doesn't
> just mean "better than nothing", but carries its weight.)
More information about the lambda-libs-spec-experts