8 ポイント 投稿者 GN⁺ 2024-10-09 | 1件のコメント | WhatsAppで共有
  • 通貨金額の操作は一般的なコンピューティング作業だが、主要なプログラミング言語には金額を表す基本データ型がない
  • そのため、分割払い、外国為替取引、手数料処理、税金徴収のような作業で丸めの問題が発生する可能性がある
  • Money は金額の計算と割り当てを簡単にするためのKotlinライブラリ
    • 金額の数学演算、パーセンテージ計算、割り当てをサポートし、さまざまなユースケースをモデル化できる
    • 暗号資産も標準でサポートする
  • 割り当て機能
    • ライブラリの最大の利点の1つは割り当て機能
    • 金額を複数の部分に分けても、元の金額と同一であることを保証する
    • たとえば、顧客が USD 100.00 の購入を3回の分割払いで支払う場合、丸めの問題による損失を防げる
  • 割り当て方法
    • allocate() メソッドを使って、元の金額との差分が生じない結果を保証する。
    • 比率に応じて割り当てるには、Percentage の値をリストで渡す。
    • デフォルトではライブラリが差分を自動で割り当てるが、望む割り当て戦略に調整可能。
  • まとめ
    • この記事はライブラリの機能を簡単に紹介したもの。
    • APIを簡潔に保ちつつ、Android開発のサポートや永続化・シリアライズ機能を段階的に拡張していく予定。
    • 現在のバージョンが、Kotlinプロジェクトで金額を扱う人々にとって有用であることを願っている。

GN⁺の要約

  • 金額を扱うことはプログラミングでよくある作業だが、丸めの問題によって複雑になることがある。
  • Moneyライブラリは、こうした問題を解決するために設計されたKotlinライブラリで、金額の正確な割り当てと計算をサポートする。
  • このライブラリは306種類の通貨と2283種類の暗号資産をサポートしており、Kotlinプロジェクトで金額を扱う際に役立つ。
  • 類似機能を持つ他のプロジェクトとしては、JavaのJoda-Moneyライブラリなどがある。

1件のコメント

 
GN⁺ 2024-10-09
Hacker News の意見
  • infix 関数の使用がやや不自然に感じられる

    • KotlinでAPIを設計するなら、一般的な拡張関数や拡張プロパティを使うと思う
    • increaseBydecreaseBy の代わりに plusminus をオーバーロードしなかった理由が気になる
  • ライブラリの公開おめでとう、そして共有に感謝

    • F# や C# の単位システムは金銭計算と似ているかもしれない
    • Rustで正確性を重視したバックテスターを開発中で、資産は通貨で評価される
    • シミュレーション時に取引所が常に稼働していると仮定できるのか気になる
    • 為替レートに関する公開データがあるのか気になる
    • 取引時にどの為替レートを選ぶべきか気になる
    • 丸めの最善の方法があるのか気になる
    • 税金を即時に控除するのがよいのか気になる
    • インフレをモデル化するか悩んでおり、今は無視して最後に調整する予定
  • Rebolの金銭型の使いやすさを思い出させる

    • Rebolの型システムは非常に表現力があった
    • こうした体験を提供するライブラリがもっと増えてほしい
  • 金銭処理で発生するエッジケースについての質問

    • 異なる通貨の値を足すとランタイム例外が発生すると予想する
    • $2.00 を 3 で割るときに丸め規則を指定できるのか気になる
    • ユーザー入力をパースする際、余分な桁をどう扱うのか気になる
    • 桁数の規則から外れた場合にライブラリがどう処理するのか気になる
  • ユーザー定義通貨のサポートが気に入った

    • 通貨記号は地域によって異なるため注意が必要
    • CLDR データセットは通貨表示を扱う実装の大半で使われている
  • スプレッドシート言語が金銭をうまくサポートしていないのは不思議

    • スプレッドシートを使った自動化は便利で、型を真剣に扱う言語では驚くような結果が得られる
  • C# の decimal 型は金銭計算に適している

  • コメントから多くを学び、ライブラリの次の改善に役立てるつもり

  • ライブラリよりも、あらゆるエッジケースを扱う徹底したテストスイートが欲しい

    • 厳格な型の使用について考えがある
    • 多くの低水準プログラミング言語がいまだに uint64 や size_t などを使っているのは奇妙に感じる
  • 要件をすべて満たしているように見え、金銭処理の主な難しさについて良い議論がある