Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
On May 2, 2012, at 8:39 AM, Stuart Marks wrote: It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. stream.infix(,).join(new StringBuilder()).toString() Indeed :-) [Paul ducks as he makes up stuff!]: String s = stream.interpose(,).reduce(new ToStringReducer()); since join can be considered a reduce operation, and the above could be equivalent to: String s = stream.interleave(repeat(,)).drop(1).reduce(new ToStringReducer()); [*] As well as: String s = stream.join(,) // can be optimal implementation specific to strings, String.join could defer to this or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned String.join(,, ...bunch of strings...) Yes. Paul. [*] interleave could support one or more streams
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
On May 1, 2012, at 2:40 PM, Rémi Forax wrote: 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. I was questioning whether the creation of such objects are necessary, not the definition of a class of such an object. i.e. while zip/unzip could be used it does not seem particular efficient for the interleave use-case (especially when three or more streams are interleaved). Paul, I think this discussion should be moved to lambda-dev. It will be more fruitful. Given the context with core libraries i kept it on the same list for now. Paul.
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
I'm just now reading State of the Lambda and beginning to get a handle on this discussion, which makes sense to me today (and didn't yesterday morning). (All this stuff about reduce is definitely taking me back to my APL days. s - ./list -- a concat/reduce operation (sans the delimiter of course)) Once I come up to speed more thoroughly I'll take a shot at this with join. Your comments are definitely giving me food for thought. Thanks, JIm On 05/03/2012 04:38 AM, Paul Sandoz wrote: On May 2, 2012, at 8:39 AM, Stuart Marks wrote: It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. stream.infix(,).join(new StringBuilder()).toString() Indeed :-) [Paul ducks as he makes up stuff!]: String s = stream.interpose(,).reduce(new ToStringReducer()); since join can be considered a reduce operation, and the above could be equivalent to: String s = stream.interleave(repeat(,)).drop(1).reduce(new ToStringReducer()); [*] As well as: String s = stream.join(,) // can be optimal implementation specific to strings, String.join could defer to this or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned String.join(,, ...bunch of strings...) Yes. Paul. [*] interleave could support one or more streams
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
On 5/1/12 10:16 AM, Rémi Forax wrote: On 05/01/2012 05:50 PM, Jim Gish wrote: Should I proceed with improvements to String.join() or wait, for example, until the lambda array support is there? better to ask Brian Goetz :) Hi guys, this came back around to me internally to Oracle since I've been kicking around some similar ideas in the context of lambda, though nothing has made it to the lambda repos yet. Unfortunately, while I don't think there is a direct dependency of String.join on any of the lambda stuff, we will probably want to coordinate the creation of these APIs. We don't want to put stuff into the mainline now, and then pull it out or retrofit it when the lambda stuff gets integrated later. So, strange as it may seem, it may be better to work on this in the lambda forest. It's not clear to me that we have to move the discussion over to lambda-dev though. This is at least as much about libraries as it is about lambda. (For those watching at home, the background regarding how this relates to lambda is described in [1] with some discussion starting at [2]. In a nutshell, the lambdafied libraries approach we're taking is to use lambda expressions to operate on streams of values. Right now streams look like Iterables but this is going to change. We want to be able to join streams of stringy things as well as arrays and collections.) It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. stream.infix(,).join(new StringBuilder()).toString() or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned String.join(,, ...bunch of strings...) s'marks [1] http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html [2] http://mail.openjdk.java.net/pipermail/lambda-dev/2012-April/004758.html
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
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. 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. Paul. Rémi
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
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)))
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?
Paul.
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
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
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
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. 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? Paul.
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
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. About the patch, you don't need to check the parameter in String because you will test them in AbstractStringBuilder. Given that you don't have to store the exception message in String anymore. (by the way, the static fields are declared transient which is really weird, as far as I know, we don't serialize static field values). Rémi On 04/28/2012 12:21 AM, Jim Gish wrote: This enhancement proposal has a long history. The most recent attempt to get some String.join() methods was by Joe Darcy back in 2009 ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-October/002967.html) He started with the changes that Remi Forax had done 8 months prior to that, which Remi had attempted a year before that! I've taken the work that Remi and Joe did and am trying again. There was a lot of discussion that was generated and that is why this has died on the vine a number of times. I realize that the current proposal may also generate discussion, but I think this had merit 4 years ago and still does. We won't satisfy everyone. It may not be perfect (what is?!), but if we can look at it from the perspective that something is better than nothing, then we ought to attempt a quick review and get this in. Having said that, I ask that you please take a look at the http://cr.openjdk.java.net/~jgish/5015163/webrev/ http://cr.openjdk.java.net/%7Ejgish/5015163/webrev/ Just a few words, based on the previous discussion, to set some context. * join() is (roughlty) intended to be the inverse of split() * example: Hi there.join(-, Bill, Joe, Zoe) will yield Hi there-Bill-Joe-Zoe * in the original proposal the delimiter character was what you started with, i.e. o -.join( Hi there, Bill, Joe, Zoe) yielded the same result as above o it seemed awkward to have the delimiter be the String instance that the join was performed on. I agree and so have made the first parameter of the join be the delimiter. * there was a lot of discussion about the pros and cons of making join() a static method vs an instance method. The point was made then, and I concur, that given that split() is an instance method, it only makes sense that join() be one too. Certainly there are other perspectives on this and one could argue the merit of each and every one of them, but in the interests of progress, I think the the split()/join() similarity argument is the most compelling and natural. Thanks, Jim Gish
