Underscore() should not automatically transform to lowercase

[gordon-matt]

I don't think Underscore() should automatically transform to lowercase. I need a way to transform pascal to underscore without changing case and that does not seem possible with Humanizer.. it automatically changes the casing.

[hns258]

Are there any concerns if I try to tackle this? The main issue I see here, based on #1144, is if we want to allow backwards compatibility. In other words, (apologies if this is obvious, but am new to this project), if we want to change Underscore() to keep the original casing, this may cause issues for users that previously used it and expected the automatic change to lower case. I would lean towards adding an optional parameter or overload instead to keep the original casing for users going forward but understand if people find it inelegant and non-intuitive.

[gordon-matt]

I was thinking the same thing. Have an optional parameter like convertToLowerCase = true.

Not ideal, but it would work.. and then you'd also have to do it for Kebaberize() as well..

Perhaps one can consider marking it as obsolete - to have the optional parameter removed in future (thus changing the current behavior to not modify the casing)? Because ideally we should be able to do this:

Sample Text: TheQuickBrownFox

.Underscore() -> The_Quick_Brown_Fox
.Underscore().ToLower() -> the_quick_brown_fox
.Underscore().ToUpper() -> THE_QUICK_BROWN_FOX

.Kebaberize() -> The-Quick-Brown-Fox
.Kebaberize().ToLower() -> the-quick-brown-fox
.Kebaberize().ToUpper() -> THE-QUICK-BROWN-FOX

[hns258]

Yes, thank you, was also considering marking it as obsolete but wasn't quite sure about all the subsequent steps required for it (how much time do we give users before we officially replace the method, do we create another ticket to implement the breaking change only at a certain version/time, can we provide any additional notification to users of the change (release notes?), etc.).

Sorry if it's actually all quite trivial, I previously only had to handle breaking changes from the user's side and in internal/contained systems. Admittedly, if users of this library have to handle this breaking change, it doesn't seem like it would be too difficult as long as they could trace it to this as the cause.