６１６日目

?.「至極のオナニー教本 For Men」
　あ、あたらしいな、これは！　昔なら情報教材とかでやってる所だろうが・・・ま、まぁ、少し信頼性がアップしたね・・・
　
　「アンモシート」の路線というか、微妙なオトコゴコロをくすぐるというか。こういうのキてんのん？
　あれです、じゃあ次は画像フィルタで「雨に濡れたエロ雑誌風になる」ソフトとか・・・少年〜青年の頃のキモチを思い出せますねっ！　インクにじみの効果ってあった気もしますな、そういえば。
　
　?.豆乳
　HIT_Msodクラスからenemy_tama1にある関数を呼び出して、変数処理をする。
　１１１は再帰、つまり関数が終わったらHIT_Msodに戻るんであるから、やっぱHIT_Msodが主役なのだろう・・・と思い、
　enemy_tama1の処理関数内にクラス（のアドレス）を渡して、
　enemy_tama1.neko++;
　・・・とかやっておりました。
　
　しかし今回は、クラスの処理部はまさにenemy_tama1に置いてある訳でしょう、なら・・・と
　this.neko++;
　と書いてみる、いけた。
　おお、だいぶ見やすくなったなあ・・・と思うも束の間、ここで欲が出る　テが来てる時はがめらんかいっ・・・！
　
　まさかの想いで試した
　neko++;
　これが動いた、そう再帰にしろ、enemy_tama1クラスの関数を呼び出した時点で、なんや・・・その関数内ではenemy_tama1のクラスが明示せずとも有効になっているのだろうか？
　つまりより一般化するなら
　『あるクラスの関数を呼び出した場合、そのクラスが明示せずとも使える』？
　
　場合によっちゃはこれはスゴイ汎用性を生みそうだなあ、と思いました。
　明示すれば、他のクラスとも折衷できる訳だし。
　つまり・・・”それぞれのクラスにある、クラスを示さなくてもいい関数処理を、更にどこかのクラスに移して、まとめる（引数にthisを渡す）”
　とかも可能・・・なのかね・・・？
　えーっと、しかもそれを別のクラスが呼び出す、みたいな。
　いやコードは短くなるかも知れへんけど、どこいった、あっち行った、で混乱すること請け合いだねこりゃ・・・
　ってかポインタでやれよ、的な行き詰まりさえ感じるね・・・
　
　なんかクラスを大儀にとらえているが、要するに構造体の進化系だとc++の本にはあった、それでいいんかねえ・・・。
　→そう、どうも１１１はクラスを関数の進化系として捉えてる節があるんだよな、関数には基本変数は所属しないじゃんね、関数も持てない。何かを保存するっていうのがない。処理部分なんだよな・・・
　当たり前だけど、クラスは、そのクラスのアドレスを保持している（this）。
　
　どこから来たか分からなくて混乱、じゃなくてそれは、どこから来てもいいようにするべきなんだよ・・・な。理想としては。
　
　例え処理がたくさんに散逸しようとも、中身を気にせずに済む仕様だったら、チェックするのはごくごくわずかな部分になる・・・
　
　関数は「分けること」で汎用性が増すだろうし（組み合わせられるので）
　・・・オブジェクト指向なら、より「分けられる」。
　だけんども、それでどこに何があるか、分かりにくくなる・・・。今の問題はそこなんだろうか・・・・・・
　
　?.web拍手へんしん
　・111ちゃん頑張ってるね。
4面からはDXライブラリ（ttp://homepage2.nifty.com/natupaji/DxLib/）でゲーム作ったらどう？
凄い便利なライブラリなので豆乳が使えるなら簡単にゲーム作れるよ！
　＞４面はもう無いんだ・・・お・・・。
　豆乳はDXライブラリどころか、そもそもプラグインみたいに、外部の関数などを取り入れる・・・という発想が無いんだお・・・
　入れるにしても、.tonyuというファイルの一形式として入れなくちゃいけなくて、導入が超面倒臭いうえに、書く側は豆乳の文法で全て書かないといけないんだお・・・！