[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079025#comment-16079025
]
Amey Jadiye commented on TEXT-96:
-
[~greenth] Thinking of adding some simple and easy to use tools/methods in 2.x
release.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071800#comment-16071800
]
Peter Phillips commented on TEXT-96:
Thanks very much to [~ameyjadiye] for the work and PR. I can see that
{{RandomStringGenerator}} serves a useful purpose, but I would still propose
that simpler methods are required if it is to replace {{RandomStringUtils}}.
For existing code using {{RandomStringUtils}} I wouldn't choose to do a search
and replace to convert to {{RandomStringGenerator}}. I would instead choose to
use an older version of commons-lang3 when {{RandomStringUtils}} eventually
gets removed, or alternatively just copy the class into my projects. I would
have thought that the majority of developers would do the same.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071323#comment-16071323
]
Gilles commented on TEXT-96:
bq. I want to keep both
Sorry, I mixed
{code}
withinRange
{code}
with
{code}
selectFrom
{code}
bq. direct methods like randomNumeric(), randomAlphabetic(),
randomAlphanumeric()
See an earlier comment of mine.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071290#comment-16071290
]
Amey Jadiye commented on TEXT-96:
-
I have submitted PR for accepting multiple pairs, now the questions is can we
make it more simpler and strait forward like giving direct methods like
_randomNumeric(), randomAlphabetic(), randomAlphanumeric()_ ?
TEXT-97 will able to do the task but not so simpler as Mr [~greenth] expect,
i'm +0 on this front. that is I'm Ok to add those method but Ok as well if we
don't add as TEXT-97 can do that.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070970#comment-16070970
]
Amey Jadiye commented on TEXT-96:
-
I want to keep both, i dont see any harm in that :)
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070632#comment-16070632
]
Gilles commented on TEXT-96:
IIUC, you mean to remove
{code}
withinRange(char ...)
{code}
and have
{code}
withinRange(char[] ...)
{code}
instead. That's fine with me.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070462#comment-16070462
]
Amey Jadiye commented on TEXT-96:
-
*Yes*, For scope of this JIRA I strongly believe that. what Mr. [~greenth] want
can be accommodated easily with flexibility of the API.
Ex. for
*.randomNumeric()*
{code}
char [][] ranges = {{'0','9'}};
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
*.randomAlphabetic()*
{code}
char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
*.randomAlphanumeric()*
{code}
char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070439#comment-16070439
]
Gilles commented on TEXT-96:
Would
{code}
withinRanges(char[] ...)
{code}
cover every such needs?
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070339#comment-16070339
]
Amey Jadiye commented on TEXT-96:
-
{{RandomStringGenerator}} is certainly better and flexible in terms of your
desired output and I don't know what was motivation behind deprecating
{{RandomStringUtils}} and giving away simple API's. but at some point those
simple things should be accommodated somewhere in {{RandomStringGenerator}}
*or* at least should provide more examples in Javadocs. *or* helper utilities
should me present somewhere which will bring back usefulness of
{{RandomStringUtils}} to -> {{RandomStringGenerator}}
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068285#comment-16068285
]
Gilles commented on TEXT-96:
A [related discussion|http://markmail.org/message/oc36ltduek4ahn3t] has started
in the "dev" ML.
IMHO, what is meant by {{randomNumeric}}, {{randomAlphabetic}},
{{randomAlphanumeric}} is not uniquely defined. Thus the random generator is
not the place where the selection must happen.
But I agree that helper utilities (to be defined elsewhere) that transform to
{{char[]}} (as per the API of this class) would be useful syntactic sugar.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
