Smartphonemoriyoshiの日記この広告は、90日以上更新していないブログに表示しています。2018-03-22無効値の話1moriyoshi.hatenablog.com先日このような駄エントリを書いた。十分ユニットテストがあればきっと防げたであろう問題であるが、それよりも、なぜnilが必要だったのかという点で疑問を感じるコメントが散見されたので、その点を補っておきたい。用いるか値型をそのポインタ型にする必要がある。*string}どちらを採用すべきかという点では議論がある。型のセマンティクスという観点では、SQLの文字列型は母言語の文字列型とは意味論的に違いがあるものなので、前者のように専用の型をあてがうのが妥当と言える。一方で、ORマッパーというからには、データストアの詳細ができるだけモデルに露出しないほうが望ましいという考え方がある。表現していたのである。表現されたモデルを対応付けする場合にも同じような問題がある。*val.Users[0].Name)}https://play.golang.org/p/bcKXLM8UoN1encoding/jsonのマーシャリングでも、JSONの文字列型を表現する専用の型を用意してあてがうことは可能だ。nullに対応付けることもできる。型システムにおいて、無効値に相当するものが定義されていた場合に、どう対応付けを行うかという視点で考えてきた。アプリケーションの設計という意味では、また別の観点もある。SQLであろうとJSONであろうと、母言語のデータ構造との1-to-1マッピングを前提とするならば、そもそもセマンティクス上の不整合が出るようなスキーマ設計をしないということものだ。NULL制約を付加すべきで、JSONであれば、null値が来るような仕様にしないといった具合である。後者の意味合いが強い。いう特別な組み込み型が用意されていることから、JSONにおけるnullの役割は、前者を示唆するものとなっている。このように、他方言語として取り上げている2つに関してだけでも、何も対処をせずに不整合を避けることはできず、そのような観点にも一理あるといえる。(たぶん続く)*1:ただし、異なるinterface型や異なるポインタ型同士の関係演算は定義されていて、異なるnil同士の同値関係が成立する。さんよりお便りをいただきました。読んであったので説明しとく。