アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
オブジェクト指向プログラミング (スコア:2, 興味深い)
だけではアレなので、ちょっと補足を。
各マイコンをプログラミングできるなら、プログラムの構造が目に見えますね。
Re:オブジェクト指向プログラミング (スコア:1, すばらしい洞察)
#そこまでデカいもん作らんか
Re:オブジェクト指向プログラミング (スコア:3, 参考になる)
再利用って、出来るんだろうか?
作り次第だけど、もしかして出来ないかも?
というのは、機能(であるブロック)に、恐らく状態がべったり張り付いているので、
1つの処理構造を複数の処理から呼ぶことが出来ない、んじゃないかと。
実際のプログラムでは、同じ関数を二度呼んでも、ローカル変数とかの「状態」は
毎回新たに作られていて、しかも互いに干渉しないわけで。
まあ、「再帰」を諦めればいい、という話もあるけど。
#「MidiPipe」を作ったときに、
#自作のPipeの組み合わせの「関数」化を行なう
Re:オブジェクト指向プログラミング (スコア:2, 参考になる)
再帰呼び出し等で必須の「再入(reentrant)」可能かどうかの話とは
関係ないのではないですか。同一のランタイムユニットによる再利用
というよりかは、異なるユニット間で同じコードを改変する事なく
利用できるかどうかが「再利用」性に関わるのではないかと。
(システムの設計上、両者が不可分である場合もあるでしょうが)
I-Blocksの件においては、そもそもデータフローに近い設計なので
比較のしようがありませんが、仮にブロックのある塊を「オブジェクト」
だと思うにしても、それらは当然のようにインスタンスなので、
再入も再利用もないもんだ、と思います。仮に、その塊を「関数」あるいは
「手続き」だと思うとすれば、再入可能にする事は不可能ではないかも。
ただ、結線を工夫しないと難しいかな。(入口:出口の対を複数持てる
ようにすれば良い。ただし排他制御が必要になる)
Re:オブジェクト指向プログラミング (スコア:1)
Re:オブジェクト指向プログラミング (スコア:1)
うーん。まずこの話は(前に書いたように)OOPの話じゃないんですよね。
あと、OOPでだって再帰をやりますから
(OOPかどうかと、再帰とかがあるという意味での手続き型かどうかと、は事実上直交なので)、
「OOPの話で」という限定にはあまり意味がないと思っています。
>同一のランタイムユニットによる再利用
>というよりかは、異なるユニット間で同じコードを改変する事なく
>利用できるかどうかが「再利用」性に関わるのではないかと。
実体プログラミングの場合、
Cut&Pasteは出来てもCopy&Pasteは出来ない、つまり
普通の意味での再利用をしようとしたら元の回路をぶっ壊さないとならない(^^;ので、
それを再利用と呼ぶのは、なんか違うような気がしています。
#一旦手にしたものを壊すのが凄く苦手なのでG7
#その点、一般的なソフトウェアは、真の意味で壊さずに済むんで、凄く助かっています。
>仮にブロックのある塊を「オブジェクト」
>だと思うにしても、それらは当然のようにインスタンスなので、
>再入も再利用もないもんだ、と思います。
Smalltalkみたいなやり方を見ていると、
インスタンスの再利用という概念もあるような気がしてきます。
Smalltalkとまで言わなくても、永続オブジェクトとかオブジェクトを(R)DBに保存するとか
という世界でも、似たような感じかな。
狭義の「プログラム」が終わっても尚消えずに残るようなオブジェクトには、
それ自体に「再利用」という道が拓けてるんじゃないかと。
>ただ、結線を工夫しないと難しいかな。(入口:出口の対を複数持てる
>ようにすれば良い。ただし排他制御が必要になる)
排他するか、陰でコッソリと"インスタンス"を複数作るか、どっちかですね。