9
ほとんどの「よく知られた」命令型/オブジェクト指向言語が、「何もない」値を表すことができる型への未チェックのアクセスを許可するのはなぜですか？
null（たとえば）の代わりに持つことの（不）利便性について読んでいMaybeます。この記事を読んだ後、私はそれを使用する方がはるかに良いと確信していますMaybe（または同様のもの）。しかし、すべての「よく知られた」命令型またはオブジェクト指向プログラミング言語がまだ使用しておりnull（「何もしない」値を表すことができる型への未チェックのアクセスを許可します）、そしてMaybeほとんどが関数型プログラミング言語で使用されていることに驚いています。 例として、次のC＃コードを見てください。 void doSomething(string username) { // Check that username is not null // Do something } ここで何か悪臭がします...引数がnullかどうかを確認する必要があるのはなぜですか？すべての変数にオブジェクトへの参照が含まれると仮定すべきではありませんか？ご覧のとおり、問題は、定義上、ほとんどすべての変数にnull参照が含まれている可能性があることです。どの変数が「null可能」で、どれがそうでないかを判断できたらどうでしょうか。これにより、デバッグと「NullReferenceException」の検索中に多くの労力を節約できます。デフォルトでは、null参照を含むことができる型はないことを想像してください。その代わりに、本当に必要な場合にのみ、変数にnull参照を含めることができると明示的に述べます。それが多分背後にある考え方です。場合によっては失敗する関数（ゼロ除算など）がある場合は、Maybe<int>、結果がintである可能性があることを明示的に示しますが、何もありません！これは、nullではなくMaybeを好む理由の1つです。他の例に興味がある場合は、この記事を読むことをお勧めします。 事実は、ほとんどの型をデフォルトでNULL可能にするという欠点にもかかわらず、ほとんどのオブジェクト指向プログラミング言語は実際にそれをNULL可能にします。それが私が疑問に思う理由です： nullプログラミング言語ではなく、どのような引数を実装する必要がありMaybeますか？理由はありますか、それとも単に「歴史的な荷物」ですか？ この質問に答える前に、nullとMaybeの違いを理解してください。