Universal Currency#to method

[MrIvanPlays]

iirc we had that in earlier iterations of v1 development. what are your opinions on adding this in v2?

default CompletableFuture<Response<BigDecimal>> to(Currency to, ...) 

[lokka30]

We did discuss this in v1 – I suggested that currencies could be converted based upon their 'relative exchange rate' e.g. Currency X has a value of 1.3, Currency Y has a value of 0.7, and Currency Z has a value of 1.0.

These values are not relative to each other, they are relative to a possibly non-existent currency. @MrNemo64 made code a while back which calculated this.

Original discussion: #3
Rework discussion: #49

[MrIvanPlays]

I mean, the current problem with migrating currencies (and the reason why I'm waiting for @Jikoo to review the migration update PR) is when we're migrating from 1 primary currency of provider x to another currency of provider y. How will provider y know how to convert the migrated currency z from provider x to currencies of provider y? That's why I was initially against the currency system we currently have in place.

[lokka30]

I mean, the current problem with migrating currencies (and the reason why I'm waiting for @Jikoo to review the migration update PR) is when we're migrating from 1 primary currency of provider x to another currency of provider y. How will provider y know how to convert the migrated currency z from provider x to currencies of provider y? That's why I was initially against the currency system we currently have in place.

With the system I am speaking of, the provider immediately knows how to convert it to any currency, since they are all allocated with the 'central-relative exchange rate'.

[lokka30]

It is the server owner's job to choose which proportions currencies A, B, C, etc are valued compared to each other. This detail, unless hard-coded, is not something that needs special migration logic (to my understanding).

[MrIvanPlays]

exactly.

[lokka30]

so your concern is resolved? :)