orange
さんがブースト
orange
さんがブースト
型でも同じようなことをやってほしくて、「なんでも単一の型を用意してドキュメントで補足するよりも、 Result とか Option とかその他『意味だけを表明する容れ物』を利用して意図する型を作る方がよい、という感じです
orange
さんがブースト
たとえば「なんでも goto を使うより while や for や iterator を」とか「なんでも再帰を使うより map や filter や fold を」みたいなのと同じで、高階のものとパラメータを組み合わせることで制約を人間にとってわかりやすく、かつ機械が理解可能な状態で表現するということが可能になります
和平・・・・＞＜(？)
orange
さんがブースト
ていうかRustとか的発想(？)で言うならば、「なんとか型」と「なんとかが壊れてる型」を作って、後始末に必要なものはどちらにも持たせるってすれば、オレンジの発想に近い？＞＜
「壊れてるかもしれない」ってモデル、かなり楽な考えだと思うんだけど＞＜；
難しい・・・＞＜；
URLだとあれだけど、URLの型の変数を作ろうとして準備してしまった何らかのリソースを失敗した結果好きな順番(環境上の都合に適した順番)で後始末したいって発想がある＞＜；(小さなもの(？)なら例外の所から逆に破棄していけばなんとかなるけど、そうじゃない何らかのハードウェア上の都合とかがある場合に・・・＞＜)
orange
さんがブースト
Rust の話になってしまうけど、エラーも結局単なる型と値として扱われるので、特になにかフローが滅茶苦茶になったりすることはないです
orange
さんがブースト
あと例外のフローについては、それは単に例外の扱いが悪い言語に慣れているのではみたいな気持ちです
orange
さんがブースト
orange
さんがブースト
私は「Url 型の値として存在させる」こと自体が「URL として不正でないものとして扱っている」と見做しているので、その辺りか
壊れていても壊れていなくても後始末はしないといけないので、壊れてるって状態もあるモデル(という普段オレンジが物事を考える時に使う発想)が、ちょうどそれにぴったりかも的なアレかも＞＜
(なので、逆に「状態なんてバグの原因にしかならない」って発想から見たら、状態なのでバグの原因かも＞＜)
基本的にはURLとして不正な文字列を内部に持つUrlは存在しない方がいいかも＞＜ なので不正ではないかのように扱おうとした瞬間に例外をはいてほしいんけど、
ただし！＞＜；宣言や、コンストラクタを呼ぶ場面だけは例外出されて後始末の流れがぐちゃぐちゃになるのがいやなので、そんな変な事に＞＜；
orange
さんがブースト
1. String → Url
2. Url に対してなんらかの操作 (たとえば path を得るなど)
のどちらでエラーが出るかという話はわかるんですが、 URL として壊れた文字列の扱いについての言及がよくわからない
オレンジ的にはURLはURLであって(さっきの例に限って言うのであれば)文字列ではなくて、不正な文字列から作られたurlは、urlを作りたかったけど失敗してぶっ壊れたもので、文字列は明示的にrawな文字列として取り出す場合以外では、例えば文字列型にキャスト出来るのであれば、その時にも例外を出してほしいかも＞＜；
orange
さんがブースト
たとえば「文字列を URL にしたい」が失敗したとき出てくるのは「URL にしたかったけどできなかった『文字列』」であるわけで、であればこれは Url 型で表現できなくても文字列型として表現できるわけで、「正しい状態しか表現できない」というのはそういう程度の話です
orange
さんがブースト
「正常でない」にも複数種類あるわけで、いわゆる異常系と正常系みたいな話になるけど……
- ＠orange_in_space
2017年 4月に登録
