I have needed / hacked all of these in the past Daniel it would be great
if they were in Commons.
On 8/8/2023 4:03 PM, Daniel Watson wrote:
I have a bit of code that adds the ability to parse and format strings into
various case patterns. Wanted to check if it's of worth and in-scope for
commons-text...
Its a bit broader than the existing CaseUtils.toCamelCase(...) method.
Rather than simply formatting tokens into the case, this API adds the
additional goal of being able to transform one case to another. e.g.
SnakeCase.format(PascalCase.parse("MyPascalString")); // returns
My_Pascal_String
CamelCase.format(SnakeCase.parse("my_snake_string")); // returns
mySnakeString
KebabCase.format(CamelCase.parse("myCamelString")); // returns
my-Camel-String
//Note that kebab and snake do not alter the alphabetic case of the tokens,
as they are essentially case agnostic joining, according to this
implementation. Though this can be overridden by end users.
The API has one core interface: Case, which has format and parse methods.
There is a single abstract implementation of it - AbstractConfigurableCase
- which is a configuration driven way to create a case pattern. It has
enough options to accommodate the 4 popular cases, and thus the subclasses
just have to configure these options rather than implement them directly.
Any further extensions can override or extend the api as necessary.
There are five core concrete implementations:
PascalCase
CamelCase (extends PascalCase)
DelimitedCase
KebabCase (extends DelimitedCase)
SnakeCase (extends DelimitedCase)
Each has a static INSTANCE field to avoid redundant instantiation.
Some of my reasoning / concerns...
* I considered bundling all of this logic into static methods, similar to
CaseUtils, but that prevents the user from truly customizing or extending
the code for odd cases. This approach is, in my opinion, far easier to
understand, extend, and debug.
* I believe the parsing side should potentially have a loose / strict mode,
in that the logic can ignore non-critical rules on the parsing side. e.g.
the command CamelCase.parse("MyString") should work, even though the input
is not strictly camel case. Strict parsing would ensure (if possible) that
the input abides by all elements of the format.
* I'm still unsure about how best to handle reserved characters when
translating. e.g. How should
KebabCase.format(PascalCase.parse("MyPascal-String")) handle the hyphen?
Should the kebab case strip the reserved character from the token values?
Long story short - is this worth pursuing in the form of a pull request for
review? Or is it out of scope for commons-text?
Dan
--
Melloware
melloware@
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
