ソースコードによる自動シリアライズ 8

　本当はこんなことしてる場合じゃないのだが、ちょっと進めた。

　new[]{ ... } この配列の中の値を手打ちしていくと、65000を越えたあたりで「型が読み込めない」という例外が飛ぶ。intでもobjectでもなんでもそうだ。それとは別に45000を超えたあたりでdecimalだとスタックオーバーフローする。

　問題はスタックオーバーフローだと思うので、どういう経路を辿っても1万を超えない感じにしたい。どう分割するか。相手がコレクションにコレクションを積み重ねるタイプの木構造だとどこまでも深く潜っていくんだよなあ。

　今の構造だと深さ1万の木構造をデシリアライズするときに一万回関数をもぐるがスタックが持たないなあ。まあスタックオーバーフローはスタックを大きくすれば解決できるからいいか。いいのか？

　ちょっともういいや。明日面接で何を言うか考えよう。

　まてまて。LinkedListにAppendを繰り返せば、理論上スタックは全く消費しなくて済むように思うが。それはそれでいいのだけど、奥へ奥へと潜っていくものを、奥の方から逆順で構成していく形にする以外に深い関数を解きほぐす方法が思いつかない。深さいくつまで潜るとオーバーフローするんだろう。そんな木構造はこない前提にしちゃおうかなあ。

　しかし奥の方から構成したら可読性下がるよなあ。関数も長くなっちゃうし。そうなったらそうなったでまた関数を分割するはめになりそうだ。一関数にいくつ関数呼び出しを書けるのか。やっぱり5万回ぐらいかなあ。

　オブジェクトを見通しよく出来ないならソースコードシリアライズの意味が無い。コレクションをAppend化するだけでいいや。木構造を深く潜って破綻するなら破綻すればいいさ。まずそんなことも無いとは思うのだけど。深さ32の二分木ってもうメモリがもたないだろ。二分しない木だとまずいんだよなあ。そんな意味分からん構造使う奴はまあいないだろ。