RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8

Rémi Forax forax at univ-mlv.fr
Tue May 1 12:40:43 UTC 2012

On 05/01/2012 01:37 PM, Paul Sandoz wrote:
> On May 1, 2012, at 12:53 PM, Rémi Forax wrote:
>> On 04/30/2012 11:03 AM, Paul Sandoz wrote:
>>> On Apr 28, 2012, at 1:01 AM, Rémi Forax wrote:
>>>> Hi Jim,
>>>> Yes, I've basically try to submit a patch each time I've written a 
>>>> method join
>>>> in one of my application :)
>>>> The funny think (in fact it's even not funny) is that I think that 
>>>> this methods
>>>> should not be in String anymore. In Java 8, we will have defender 
>>>> methods
>>>> so you can write join directly on an Iterable. And there is some 
>>>> discussion
>>>> to also allow defender methods on arrays too,
>>>> so we may can write a method join on Object[] too
>>>> (on an interface inherited from Object[] to be precise).
>>>> I really think that list.join(",") is better than "".join(",", 
>>>> list) and
>>>> ["foo", "bar"].join(",") is better than "".join(",", ["foo", "bar"]).
>>>> but maybe I'm wrong.
>>> Good point. Although i don't see the harm with such methods on 
>>> String that defer, or are required if say defender methods on arrays 
>>> never come about.
>>> There are also more general cases of interpose and interleave (see 
>>> Clojure's functions as an example) since join can be implemented 
>>> using interpose which can be implemented using interleave.
>> Implementing interpose with interleave requires to remove the last 
>> element,
>> which is not so easy in lazy mode. It's easier to implement it directly.
> Or the first e.g.:
> http://clojuredocs.org/clojure_core/clojure.core/interpose
> (defn interpose
>    "Returns a lazy seq of the elements of coll separated by sep"
>    {:added "1.0"
>     :static true}
>    [sep coll] (drop 1 (interleave (repeat sep) coll)))

yes, it's better !

>>> Not saying join should be implemented that way (not so optimal for 
>>> Strings only) but i think such functions are very useful. I am not 
>>> tracking the lambda library work very closely, have such functions 
>>> been considered?
>> Yes, we discuss about zip/unzip, and what we call BiStream.
>> unzip is the other name of interleave.
> Would that require the creation of an intermediate object that holds 
> two values?

or reuse Map.Entry.
That are the two reasonable choices.

Paul, I think this discussion should be moved to lambda-dev.
It will be more fruitful.

> Paul.


More information about the core-libs-dev mailing list