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

Add historical currency codes #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MaxGabriel
Copy link

Closes #3

This is a draft attempt at closing #3, modeling historical currency codes

I say draft because:

  1. There are 3 codes without numeric codes. I assigned 5000, 5001, and 5002 to them as placeholders. Those currencies could be removed from the list to simplify things
  2. Many historical currencies have unknown numbers of decimal units. I defaulted those to 0. Possibly a -1 sentinel value could be used, or those currencies could be dropped entirely? I normally would try to model things faithfully, but correctly modeling would be a breaking change that only serves to model super old currencies.
  3. I need to carefully review what is in the historical list or not against the ISO standard.
  4. (Minor) I need to fix up the sorting, but holding off on that until the other stuff has a path forward

One alternative to trying to add a lot of historic currencies is to just add some on as-needed basis. For example, recent changes like HRK -> EUR are probably useful to people who have serialized HRK data, but it's less likely people need CSJ from 1953.

Any feelings on the above?

@isomorpheme
Copy link
Collaborator

Hmm - on the one hand, I personally don't mind the sentinel values much, as I don't realistically see them tripping up existing code. On the other hand, if we stick to this design, and we do want to model things differently after all, that would be a pretty painful breaking change.

My idea would be: throw more types at it, and introduce a separate type for historical currencies (and currency codes?). Then we can just use Maybe where values might be unknown, and users can make a deliberate choice about whether and how to handle those; for the most flexible case we can produce a type isomorphic to Either HistoricalCurrency Currency. This would just be an addition, so not a breaking change right now; moving a currency to historical would be breaking, but arguably that's a good thing, because then users are made aware that reality has changed (assuming it would be breaking in terms of compiler errors, not at runtime).

@isomorpheme
Copy link
Collaborator

I do realise that the question of which historical currencies one might want to handle still stands though: having to deal with a whole separate type for all historical currencies is probably annoying if you just want to handle recent cases like HRK.

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

Successfully merging this pull request may close these issues.

Include historical currency codes
2 participants