-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavior when mixing numbers and characters on a name #42
Comments
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
I'd like to have |
Hmm… The behavior was set 3+ years ago and I don't remember the details, but judging from the tests in 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. |
The function used for transforming to kebab cased keywords has an issue when the key is mixed with numbers and characters clj-commons/camel-snake-kebab#42 and exactly this is problematic for keys like `:runner-02adde85-7802-4039-9bae-85db2d366188`, because that would be transformed to `:runner-02adde-85-7802-4039-9bae-85db-2d-366188`.
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.
The text was updated successfully, but these errors were encountered: