What about forking?
2018-06-19 13:42 GMT-03:00 Paul Sandoz :
> Gosh, this is a tricky one to name.
>
> collectingTo seems the best so far, although collect(collectingTo(…)) ...
>
> One last suggestion from me, “expanding”, as in the collector expands the
> number of collectors the input elements
Gosh, this is a tricky one to name.
collectingTo seems the best so far, although collect(collectingTo(…)) ...
One last suggestion from me, “expanding”, as in the collector expands the
number of collectors the input elements are applied to.
Paul.
> On Jun 19, 2018, at 7:47 AM, Brian Goetz wr
It is "distributing" in the same sense as the distributive law:
c*(a+b) = c*a + c*b
(Think of the two collectors as the "sum" of a collector, and
"distributing" says that you can send the elements to the sum by sending
all of the elements to each.)
That said, I agree that the less mathem
I don't like `distributing` for the same reason as `bisecting`: for me, it
sounds like a Stream is giving each collector only a part of elements.
2018-06-19 19:44 GMT+07:00 Brian Goetz :
>
>
> collectingToBoth
>>
>
> This one is actually both evocative of what the method does, and in the
> spirit
collectingToBoth
This one is actually both evocative of what the method does, and in the
spirit of the existing naming conventions (collectingAndThen.)
An n-ary version could just be called `collectingTo`, where it is passed
a varargs of Collector. Could we get away with collectingTo fo
We already have some toXxx() methods (toList, toSet, toCollection,
toMap, ...), so toBoth seems to me as a natural extension of that
naming principle:
For toXxx methods, the Xxx is terminal, and tied to the result type.
toArray converts to an array; toList to a List; toCollection to a
Col
No. The essence of `mapping` is: apply this function, then pass them
down to something else. In that case, the something else is secondary
to the mapping.
The essence of this method is: split the stream into _two_ streams, so
it can be operated on by two collectors. Any mapping here is incid
On 06/19/2018 12:21 AM, Brian Goetz wrote:
distributing?
More "replicating" than "distributing" (thinking of replicated vs.
distributed caches for example).
Peter
I agree that f1 and f2 are unnecessary.
I also noticed that toBoth is a binary form of `collectingAndThen`:
public static Collector collectingAndThen(
Collector downstream,
Function finisher);
So what about `collectionToBothAndThen`?
public static Collector collectingT
Not that it's an important factor but as a non-native English speaker
I like the simplest form of "toBoth()" best. I also doubt there will
ever be a "Both" class in the JDK to worry about, even if such
examples can be found in the wild [1].
Dawid
[1] https://github.com/search?q=filename%3ABoth.ja
On 06/19/18 09:43, Peter Levart wrote:
We already have some toXxx() methods (toList, toSet, toCollection,
toMap, ...), so toBoth seems to me as a natural extension of that
naming principle:
Well, on a second thought, toList, toSet, etc... they all name a type
that is a result of the collec
On 06/19/18 02:38, John Rose wrote:
unzipping(
Function f1, // defaults to identity
Collector c1,
Function f2, // defaults to identity
Collector c2,
BiFunction finisher) {
return toBoth(mapping(f1, c1),
> On Jun 19, 2018, at 9:11 AM, Zheka Kozlov wrote:
>
> The function you propose is just a binary variant of mapping:
>
> Collector mapping(
> Function mapper,
> Collector downstream);
>
> (omitted '? super' for readability)
>
> So, it
The function you propose is just a binary variant of mapping:
Collector mapping(
Function mapper,
Collector downstream);
(omitted '? super' for readability)
So, it is logical to use the name biMapping:
Collector biMapping(
> On Jun 19, 2018, at 1:21 AM, Brian Goetz wrote:
>
> distributing?
>
> On 6/18/2018 6:04 PM, Chris Hegarty wrote:
>>
>>> On 18 Jun 2018, at 22:29, Brian Goetz wrote:
>>>
>>> "bisecting" sounds like it sends half the elements to one collector and
>>> half to the other ...
>>>
>>> "tee" mi
On Jun 18, 2018, at 2:29 PM, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other …
The main bisection or splitting operation that's relevant to a stream is what
a spliterator does, so this is a concern.
Nobody has mentioned "unzipp
Hi Peter,
Existing composing collectors tend to unpack all the functions of the input
collector ahead of time, i don’t recall being too concerned about this at the
time. It does allow for more robust null checking, something we were less
diligent about doing.
Paul.
> On Jun 17, 2018, at 3:04
distributing?
On 6/18/2018 6:04 PM, Chris Hegarty wrote:
On 18 Jun 2018, at 22:29, Brian Goetz wrote:
"bisecting" sounds like it sends half the elements to one collector and half to
the other ...
"tee" might be a candidate, though it doesn't follow the `ing convention.
"teeing" sounds du
> On 18 Jun 2018, at 22:29, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing convention.
> "teeing" sounds dumb.
Doesn’t follow the convention either, bu
Replicator (as in DNA)
Sent from my iPhone
> On Jun 18, 2018, at 6:49 PM, James Laskey wrote:
>
> Bifurcate
>
> Sent from my iPhone
>
>> On Jun 18, 2018, at 6:29 PM, Brian Goetz wrote:
>>
>> "bisecting" sounds like it sends half the elements to one collector and half
>> to the other ...
>
Bifurcate
Sent from my iPhone
> On Jun 18, 2018, at 6:29 PM, Brian Goetz wrote:
>
> "bisecting" sounds like it sends half the elements to one collector and half
> to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing convention.
> "teeing" sounds dumb.
>
>
>
Agreed. Not sure if this has been suggested, but what about duplex(ing)?
On Mon, Jun 18, 2018 at 5:29 PM Brian Goetz wrote:
> "bisecting" sounds like it sends half the elements to one collector and
> half to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing
> conve
"bisecting" sounds like it sends half the elements to one collector and
half to the other ...
"tee" might be a candidate, though it doesn't follow the `ing
convention. "teeing" sounds dumb.
On 6/15/2018 7:36 PM, Paul Sandoz wrote:
Hi Tagir,
This is looking good.
My current favorite name
Hi Tagir,
I don't know if this is important, but in your approach the particular
functions of the sub-collectors are retrieved eagerly even if they are
later not used. This should typically not present a problem as
Collector(s) should be prepared to be used in any scenario (parallel or
serial
On 06/15/18 13:31, Tagir Valeev wrote:
Peter,
> EnumSet intersection =
EnumSet.copyOf(keyCollector.characteristics());
> intersection.retainAll(valCollector.characteristics());
> return intersection;
Please note that `copyOf` should either receive an EnumSet or
non-
Hi Tagir,
This is looking good.
My current favorite name for the factory method is “bisecting” since we are
dividing the collector into two collectors, the results of which are then
merged.
Suggested first paragraph of the factory method:
"Returns a collector that passes the input elements
Peter,
> EnumSet intersection =
EnumSet.copyOf(keyCollector.characteristics());
> intersection.retainAll(valCollector.characteristics());
> return intersection;
Please note that `copyOf` should either receive an EnumSet or non-empty
Collection to obtain the enum class. T
Hello!
I created a preliminary webrev of my own implementation (no testcases yet):
http://cr.openjdk.java.net/~tvaleev/patches/pairing/webrev/
If anybody wants to sponsor my implementation, I will happily log an issue
and write tests.
The name "pairing" was invented by me, but as I'm not a native
On 14/06/18 08:46, Peter Levart wrote:
But there's no way to use partitioningBy to simulate all the variants
of toBoth...
I wasn't suggesting that - more the other way around, as you illustrated
Maurizio
Well, I don't see the need to pack the two results into a Map.Entry
(or any similar) container as a drawback.
From an "integrity of the JDK APIs" perspective, it is unquestionably a
drawback. These items are not a Key and an associated Value in a Map;
it's merely pretending that Map.Entry
Hi Peter,
I am not concerned about performance of Map.Entry. I find its use awkward for
similar reasons as Brian outlined. Tagir’s approach using a finisher nicely
side steps this at the expense of another function. If in the future we have an
officially blessed pair/2-tuple class we can overlo
In this form (not locked to Map.Entry) it seems like a candidate for
the JDK. The implementation is private, so it would be one public
method that provides a new way to process streams.
Stephen
On 14 June 2018 at 05:56, Tagir Valeev wrote:
> Hello!
>
> In my StreamEx library I created a "pairin
Hi Maurizio,
Collectors.partitioningBy is only superficially similar. It partitions
the stream into two disjunct sub-streams of elements and collects each
of them using the same collector.
BiCollector OTOH collects all the elemets of the original Stream "two
times" into two independent colle
Hi Paul,
On 06/11/18 19:10, Paul Sandoz wrote:
Hi Peter,
I like it and can see it being useful, thanks for sharing.
I am hesitating a little about it being in the JDK because there is the larger
abstraction of a BiStream, where a similar form of collection would naturally
fit (but perhaps wi
Hi Tagir,
Great! I've been thinking about the same trick - just add another
function and you don't have to hard code the decision about the choice
of imperfect tuple type. But are we just talking of aestetics here? In
the absence of value types, every choice is imperfect. Ok, sometimes you
ma
Hello!
In my StreamEx library I created a "pairing" collector which does similar
job, but allows user to decide how to combine the results of two
collectors. This adds more flexibility. The signature is like this:
public static Collector pairing(
Collector c1,
Collector c2,
BiFunctio
I really like how BiCollector can be private, so all we'd have to expose
is toBoth(), and the arguments of toBoth() are just ordinary
collectors. So no new types or abstractions; just a multiplexing.
The use of Map.Entry as a pair surrogate is unfortunate -- its
definitely not an Entry -- tho
I don’t have anything publicly available. I’ll see if i can dig something out
and send it to you directly.
Paul.
> On Jun 11, 2018, at 11:28 AM, Peter Levart wrote:
>
> Hi Paul,
>
> Can you point me to some BiStream code (if it is available publicly)?
>
> Thanks, Peter
>
> On 06/11/18 19:1
.
regards,
Rémi
- Mail original -
> De: "Peter Levart"
> À: "Paul Sandoz"
> Cc: "core-libs-dev"
> Envoyé: Lundi 11 Juin 2018 20:28:36
> Objet: Re: BiCollector
> Hi Paul,
>
> Can you point me to some BiStream code (if it is availabl
Hi Paul,
Can you point me to some BiStream code (if it is available publicly)?
Thanks, Peter
On 06/11/18 19:10, Paul Sandoz wrote:
Hi Peter,
I like it and can see it being useful, thanks for sharing.
I am hesitating a little about it being in the JDK because there is the larger
abstraction
Hi,
I’ve created one of my own and I’d happily toss it for a standard
implementation.
— Kirk
> On Jun 11, 2018, at 8:10 PM, Paul Sandoz wrote:
>
> Hi Peter,
>
> I like it and can see it being useful, thanks for sharing.
>
> I am hesitating a little about it being in the JDK because there i
Note also that this has some overlappings with Collectors.partitioningBy
- which currently wraps results into a Map, where O is the
desired collector output type. Without commenting on the feasibility of
its inclusion in the JDK (Paul rules here :-)), I note that BiStream
would obviously allow
Hi Peter,
I like it and can see it being useful, thanks for sharing.
I am hesitating a little about it being in the JDK because there is the larger
abstraction of a BiStream, where a similar form of collection would naturally
fit (but perhaps without the intersection constraints for the
chara
43 matches
Mail list logo
