This is a good idea and seems like useful functionality. In order to
accept it into commons, it needs solid documentation and excellent
test coverage. I've worked on code like this in another language (not
Java) and the production bugs were bad. E.g. what happens when a
string contains numbers as well as letters?
I'd like to see a full spec that unambiguously defines how every
Unicode string is converted into camel/snake/kebab case. The spec
should be independent of the code. That's not easy to write but it's
essential.
I don't want any loose/strict modes. It should all be strict according to spec.
I've never heard of kebab cases before. Is that a common name? I'd
also like to rename Pascal case. How many programmers under 40 have
even heard of Pascal, much less are familiar with its case
conventions?
Long story short - a PR is premature until there's an agreed upon spec.
On Tue, Aug 8, 2023 at 8:04 PM Daniel Watson <dcwatso...@gmail.com> 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
--
Elliotte Rusty Harold
elh...@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
