Skip to content
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

Open
ricardojmendez opened this issue Nov 12, 2017 · 4 comments
Open

Comments

@ricardojmendez
Copy link

There's unexpected behavior when mixing numbers and characters on an identifier which is not demonstrated on any of the tests.

This makes sense:

(->kebab-case-keyword :user_id)
=> :user-id

(->kebab-case-keyword :user_1)
=> :user-1

But then...

(->kebab-case-keyword :user1_124)
=> :user-1-124

(->kebab-case-keyword :user1)
=> :user-1

It gets worse:

(->kebab-case-keyword :object1a2)
=> :object-1a-2

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.

@jhereth
Copy link

jhereth commented Dec 12, 2017

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.

@qerub
Copy link
Collaborator

qerub commented Dec 16, 2017

@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.

@qerub
Copy link
Collaborator

qerub commented Dec 16, 2017

@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.

@jhereth
Copy link

jhereth commented Dec 18, 2017

@qerub Thanks a lot - this not only solved my issue but also taught me something new about regexps.

hamann added a commit to nextjournal/consul-clojure that referenced this issue May 16, 2019
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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants