型について

Elm の主な利点の 1 つは、ランタイムエラーが実際に起きないことです。 Elm コンパイラが非常に素早くソースコードを分析して、値がプログラム中でどのように使われているか解析できるためです。 値を間違った方法で使用すると、コンパイラがフレンドリーなエラーメッセージで警告してくれます。 これは 型推論 と呼ばれています。 コンパイラは、全ての関数の引数と返り値の型を解析します。

型推論の例

次のコードはフルネームを文字列で返す toFullName 関数を定義しています:

toFullName person =
  person.firstName ++ " " ++ person.lastName

fullName =
  toFullName { fistName = "Hermann", lastName = "Hesse" }

JavaScript や Python のように、余分なものなしにこのコードは書けます。 だけどバグがあることに気づきましたか?

JavaScript で同等のコードは"undefined Hesse"を吐き出します。 エラーですらありません! うまくいけばユーザーがこのバグを見つけたときに報告してくれるかもしれません。 対照的に、Elm コンパイラは単にソースコードを解析するだけで警告してくれます:

-- TYPE MISMATCH ---------------------------------------------------------------

The argument to function `toFullName` is causing a mismatch.
# `toFullName` 関数の引数の型が合いません

6│   toFullName { fistName = "Hermann", lastName = "Hesse" }
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Function `toFullName` is expecting the argument to be:
# `toFullName`関数は以下の型の引数を期待しています:

    { …, firstName : … }

But it is:
# しかし、実際は:

    { …, fistName : … }

Hint: I compared the record fields and found some potential typos.
# 解決のヒント: レコードのフィールドを比べたところ、typoらしきものが見つかりました。

    firstName <-> fistName

toFullName が引数の を間違って取得していることがわかります。 エラーメッセージのヒントのように、誰かが誤って firstの代わりに fistを書きました。

このような単純ミスを防ぐための仕組みは素晴らしいものですが、何百ものファイルや、変更を加えるたくさんのコラボレーターがいる場合、より価値のあるものになります。 どんなに大きく複雑なものでも、Elm コンパイラはソースコードに基づいて 全て が適切かをチェックします。

型についてより理解が深まると、コンパイラはフレンドリーなアシスタントのように感じられます。 だからもっと型について学びましょう!

results matching ""

    No results matching ""