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