最近の検索
検索オプション
ところでこれはエアリプだけど、型などでガッチリ仕様を表現せず文字列でデータを表現して持ち回る理由としては、「文字列なら enum variant の追加等と違って型そのものやその利用箇所への影響が少ない (≒コード変更なしでコンパイルが通る) ので、見掛け上の変更と影響範囲を小さくできる」などがあります。
もちろん正しく動くとは言ってない。
正しくない指標を用いて開発や成果物を改善しようとすると何が起きるかの一例ですね
まあ †ビジネス† の世界では実行時の誤りの発覚がないことよりも差分の小ささの方が正義なのかもしれないが……それは私の知ったことではないし私の関わりたくない領域の話なので
「動いているものを変更するな」とか言っちゃう世界で生きるの、健康と脳に悪い
証明のひとつでも付けてから正しさを語れという感じはある (適当)
@lo48576 XMLもJSONも独自のバイナリ表現も、型名を間接的に表すことはできても型情報そのものを持つことは無謀です。そんなことしたらコード側の変化に敏感になりすぎてしまう。
@tateisu ネイティブコードにおけるデータ構造と、通信や I/O で使われる直列化表現の橋渡しは、 {,de}serialize をうまく実装して境界を切ることで行われるべきで、むしろそれぞれが (ある程度) 独立した構造を持っているべきです。
直列化表現をネイティブロジックでそのまま使い回そうとすると型システムの恩恵などを受けられなくなり、ネイティブの構造をそのまま直列化しようとすると仰るとおり表現が安定しなくなるかロジックが変更できなくなってしまうので。