orange @[email protected]

話が無限に広がっちゃうけど、継承がないと、さっきからの例のような、壊れれない版と壊れてる版を作る時にも、ツリー状に関係を表現できなさそうで謎＞＜；

壊れてない型を継承して、壊れてるインタフェースをくっつけた壊れてる型を作れば、「これって壊れてる型？(＝壊れてるインタフェース持ってる？)」って型チェックもできるかも・・・＞＜

(限定的な)多重継承できる言語、例えばC# (のインタフェース)ならば、IBroken(？＞＜；)みたいなインタフェースを標準化して、壊れてる版はそれを混ぜた派生クラスを作ればエレガント・・・？＞＜

和平・・・・＞＜(？)

ていうかRustとか的発想(？)で言うならば、「なんとか型」と「なんとかが壊れてる型」を作って、後始末に必要なものはどちらにも持たせるってすれば、オレンジの発想に近い？＞＜

「壊れてるかもしれない」ってモデル、かなり楽な考えだと思うんだけど＞＜；

難しい・・・＞＜；

URLだとあれだけど、URLの型の変数を作ろうとして準備してしまった何らかのリソースを失敗した結果好きな順番(環境上の都合に適した順番)で後始末したいって発想がある＞＜；(小さなもの(？)なら例外の所から逆に破棄していけばなんとかなるけど、そうじゃない何らかのハードウェア上の都合とかがある場合に・・・＞＜)

壊れていても壊れていなくても後始末はしないといけないので、壊れてるって状態もあるモデル(という普段オレンジが物事を考える時に使う発想)が、ちょうどそれにぴったりかも的なアレかも＞＜
(なので、逆に「状態なんてバグの原因にしかならない」って発想から見たら、状態なのでバグの原因かも＞＜)

基本的にはURLとして不正な文字列を内部に持つUrlは存在しない方がいいかも＞＜ なので不正ではないかのように扱おうとした瞬間に例外をはいてほしいんけど、
ただし！＞＜；宣言や、コンストラクタを呼ぶ場面だけは例外出されて後始末の流れがぐちゃぐちゃになるのがいやなので、そんな変な事に＞＜；