Open ricardojmendez opened 7 years ago
Looking at the discussion in #22 I understand that there is no universal solution to how to process digits. Even worse when not having separators as in @ricardojmendez's example.
Is there any way to specify that numbers should be treated as part of the preceeding part and not be treated as part of itself, e.g. instead of
user=> (csk/->snake_case_keyword "FooSP1")
:foo_sp_1
I'd like to have :foo_sp1
.
@ricardojmendez:
Thoughts? What was the rationale behind this?
Hmm… The behavior was set 3+ years ago and I don't remember the details, but judging from the tests in string_separator_test.cljc
I wanted a string like "Adler32" to be split into ["Adler", "32"] which still makes sense.
Regardless of whether this behavior is good or not, it's too late to break it as you say. The only sustainable way to resolve this issue (and others like it) is to extend the API to allow specifying the input case. This will be implemented in response to #38 and I am hoping to have this ready during my winter/Xmas vacation.
@daten-kieker:
The best workaround at the moment is to specify your own word separator pattern, e.g.:
(->snake_case_keyword "FooSP1" :separator #"(?<![A-Z])(?=[A-Z])")
; => :foo_sp1
https://www.regular-expressions.info/lookaround.html has some good docs describing the negative lookbehind and positive lookahead used here.
@qerub Thanks a lot - this not only solved my issue but also taught me something new about regexps.
There's unexpected behavior when mixing numbers and characters on an identifier which is not demonstrated on any of the tests.
This makes sense:
But then...
It gets worse:
While I can see from the source this is the intended grouping behavior, this goes agains the principle of least surprise. I'm not sending a PR to change it since I expect it would break existing use (need to assume that someone, somewhere is relying on this).
Thoughts? What was the rationale behind this?
This looks related to #22.