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

Make default lowercase everywhere #16

Open
ad-si opened this issue Jan 20, 2024 · 6 comments
Open

Make default lowercase everywhere #16

ad-si opened this issue Jan 20, 2024 · 6 comments

Comments

@ad-si
Copy link
Member

ad-si commented Jan 20, 2024

https://endtimes.dev/why-lowercase-letters-save-data/

@TheInnerLight
Copy link

TheInnerLight commented Sep 25, 2024

The Crockford spec says "When encoding, only upper case letters are used." so I wouldn't expect this to be the default behaviour.

@ad-si
Copy link
Member Author

ad-si commented Sep 25, 2024

It also says:

When decoding, upper and lower case letters are accepted,

Which I read as "pick whatever style you prefer". His is upper-case, mine is lower-case.

@ad-si
Copy link
Member Author

ad-si commented Sep 25, 2024

He also says that it should "be human readable".
I think lowercase is much more readable, because characters have different heights and some even extend beyond the baseline and therefore it's much easier to keep track of where you are.

@TheInnerLight
Copy link

TheInnerLight commented Sep 25, 2024

It also says:

When decoding, upper and lower case letters are accepted,

Which I read as "pick whatever style you prefer". His is upper-case, mine is lower-case.

The spec is very clear that you should:

  • Use your preference when decoding.
  • Use upper case when encoding.

When decoding, the library already calls toUpper (https://github.com/haskell-github-trust/ulid/blob/b80ae2c2f2cb7b0c9c29973c762135623df23413/src/Data/ULID/Base32.hs#L36C31-L36C38) so lower case ULIDs would be decoded correctly.

@ad-si
Copy link
Member Author

ad-si commented Sep 25, 2024

You can not have a spec where any casing can be decoded, but then request that it is encoded in a certain way. Either you allow any casing or you don't. Therefore I'm considering it a personal preference of him. One I don't agree on that is.

@TheInnerLight
Copy link

TheInnerLight commented Sep 25, 2024

You can not have a spec where any casing can be decoded, but then request that it is encoded in a certain way. Either you allow any casing or you don't. Therefore I'm considering it a personal preference of him. One I don't agree on that is.

You're absolutely welcome to disagree and have whatever personal preference you like but if you want to diverge from the spec in the implementation, I would suggest you should either:

  • Convince Douglas Crockford to update the Crockford spec to prefer encoding in lower case.
  • Convince the authors of the ULID spec to switch from using the Crockford spec to a modified version that prefers lower case.
  • Introduce a newtype wrapper e.g. LC ULID so that you have a choice of whether to opt in to non-standard behaviour.

FWIW, this is not unusual. In something as ubiquitous as the URI syntax spec (RFC 3986), the section on % encoding says (emphasis mine):

The uppercase hexadecimal digits 'A' through 'F' are equivalent to the lowercase digits 'a' through 'f', respectively. If two URIs differ only in the case of hexadecimal digits used in percent-encoded octets, they are equivalent. For consistency, URI producers and normalizers should use uppercase hexadecimal digits for all percent- encodings.

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

2 participants