-
Notifications
You must be signed in to change notification settings - Fork 264
New and useful methods for commons.text.CaseUtils #528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am missing the rationale for embedding the stripping of accent chars into the notion of converting to title case, or any other conversion. You are already delegating to a utility method for this purpose; couldn't the API consumer do that it needed? I would also prefer a design more like one common implementation with parameters for delimiter, case(, etc.?) rather than e.g. kebab = snake + s/_/-/ .
Additionally, I have a preference for "Pascal" to "upper camel" for the seeming uniformity of having a single word to describe the desired structure, notwithstanding combinations like "screaming snake."
You make some good points, to have at most one or two methods with a
parameter for delimeter. I will revisit this.
One concern is the existing char[] for delimeter in the existing
toCamelCase method is to define delimiters to exclude, where my methods
would use a char or string for character to use between words.
I will definately revisit this and do a new push to my fork.
Thank you.
…On Wed, Apr 10, 2024, 09:35 Matt Benson ***@***.***> wrote:
***@***.**** commented on this pull request.
I am missing the rationale for embedding the stripping of accent chars
into the notion of converting to title case, or any other conversion. You
are already delegating to a utility method for this purpose; couldn't the
API consumer do that it needed? I would also prefer a design more like one
common implementation with parameters for delimiter, case(, etc.?) rather
than e.g. kebab = snake + s/_/-/ .
Additionally, I have a preference for "Pascal" to "upper camel" for the
seeming uniformity of having a single word to describe the desired
structure, notwithstanding combinations like "screaming snake."
—
Reply to this email directly, view it on GitHub
<#528 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF72ZOZZWHFOZSZAMUOFPZDY4U52LAVCNFSM6AAAAABF7LF7D6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSOJRG4YTIMJUGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I've rewritten the code in CaseUtils based on comments and some more aggressive tests I devised. I've removed many unnecessary methods such as toScreamingCase, etc. that can be easily reproduced by a user. I changed the main engine to toDelimitedCase, which accepts a boolean to uncapitalize the very first letter of the string, and a "separator" (to differentiate it from delimiters in the existing CamelCase()). I retained my toCamelCase(str), toPascalCase, toSnakeCase, and toKebabCase even though these could be reproduced by a user using toDelimitedCase to make it easier for a user. I also wrote some very aggressive tests with null values for all parameters, line breaks, tabs, etc. This is what you get in the revised version:
|
This adds several methods to CaseUtils, that allow a user to convert a string to a variety of cases. These methods normalize the strings to ANSI Latin.
I've created new tests from the existing tests for
toCamelCase(String, boolean, char[])
and run them, all the output is as expected.The main driver engine for the new methods is in toTitleCase().
This is what you get...