ALSI.CaseConversions is a .NET library that converts various string formats into other cases. It provides robust handling of different casing conventions, separators, and special characters, making it an ideal utility for consistent string formatting in your applications.
It'd be great to be able to expand to more complex casing requirements, such as (non-exhaustive):
TitleCase -> "the_ball_is_in_your_court" => "The Ball is in Your Court"
MidSentenceCase -> "the_ball_is_in_your_court" => "the ball is in your court" (possibly easy)
StartSentenceCase -> "the_ball_is_in_your_court" => "The Ball Is In Your Court" (possibly easy)
This would require encoding more semantic information at some point beyond just each ASCII character, so it'd have to be carefully designed to not invoke too much overhead. It'd absolutely be slower, as you'd need to track the exact parsed word, so we'd be heading into lexer territory.
I'm envisioning some way of creating a mask span that can reject certain combinations of letters in a "word", but that would require some complex mask combinations.
i.e. for TitleCase:
receive char 'i' => possibly lower case
second char 's' => still possibly lower case
{
3rd char delimiter => "is" wasn't rejected => lower case
3rd char 'l' (as in "island") => 'l' rejects the word => continue with title case and don't check the rest of the word
}
There is a LOT of semantic information to encode if we go down this route, as lower-case words in a title aren't limited to just articles, but also includes a subset of prepositions, co-ordinating conjunctions, subordination conjunctions etc. that would need to be exhaustively encoded.
It'd be great to be able to expand to more complex casing requirements, such as (non-exhaustive):
TitleCase -> "the_ball_is_in_your_court" => "The Ball is in Your Court" MidSentenceCase -> "the_ball_is_in_your_court" => "the ball is in your court" (possibly easy) StartSentenceCase -> "the_ball_is_in_your_court" => "The Ball Is In Your Court" (possibly easy)
This would require encoding more semantic information at some point beyond just each ASCII character, so it'd have to be carefully designed to not invoke too much overhead. It'd absolutely be slower, as you'd need to track the exact parsed word, so we'd be heading into lexer territory.
I'm envisioning some way of creating a mask span that can reject certain combinations of letters in a "word", but that would require some complex mask combinations. i.e. for TitleCase:
There is a LOT of semantic information to encode if we go down this route, as lower-case words in a title aren't limited to just articles, but also includes a subset of prepositions, co-ordinating conjunctions, subordination conjunctions etc. that would need to be exhaustively encoded.