//List以外のObjectを作る意味がさっぱりないじゃないですか。
//一応Type指定することで、同一の型だった場合に同じようにアクセスできるtraitみたいな機能を用意するべきだろうか。
//概念整理のためにObjectを分けるというのは考え方ではあるけど、それによって互換性は破壊されてしまう。

//で、そうした場合に、undefinedを用意する必然性は確保できるだろうか。
//objectをundefinedにした場合、うれしいことは、undefinedだった場合にobjectの中身を計算して別のものに変えられること。
//ダメな点は、オブジェクトの中身にアクセスしようとしたときに何を出せばいいのかわからないこと。

//undefinedのオブジェクト自体はundefinedにはならないけど、中身のundefined可能なメンバはすべてundefinedになる、という折衷案が良さそうに思う。
//objectをundefinedにするのはやっぱり良くないと思う。オブジェクトの中のundefined可能でない部分をどう考えるか不明になるし。

結局objectの中にobjectを用意する必然性が分からないままだ。概念整理にはなるかもしれないけど、そもそもそんな機能は必要ないという説も濃厚である。

Includeを行うためには必須の機能であり、Includeは必須の機能なので、やはり必須の機能である可能性は高そうだが・・・

いったんObjectの中にObjectを作る機能はなしでいこうかと思う。必要である理由がさっぱりわからないわりに作るのが大変でファイルの見通しも悪くなると思う。
トップのオブジェクトに全部の制御情報がはいり、下にはひたすらListが生えるというのがわかりやすい形になると思う。ListIDの一元管理の意味でもその方がキレイだ。

結局オブジェクトのメンバをいくつかまとめて一つのオブジェクトにして、オブジェクトから生やすという行動をとった時、名前変更のトラッキングでは間に合わないし
根本的に圧倒的な破壊的変更になってバージョン感で互換性を保つ方法がなくなってしまう。バージョン間の互換性がなくなるすべての変更を避ける必要があるというのが
このシステムの根っこなので、これは受け入れられない。