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

[Rémi Forax]

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.

cheers,
Rémi