В 1997 г. Borland открыла исходные тексты Turbo Vision на C++ и на их основе сторонние разработчики стали создавать свои реализации библиотеки. Исходные тексты Pascal-версии Turbo Vision 1.0 поставлялись в комплекте с Turbo Pascal 6.0, а исходники Turbo Vision 2.0 включались в Borland Pascal 7.0 и Turbo Pascal 7.0. В комплекты поставок также...
PascalのTurboVisionを彷彿とさせるようなアプローチだ。ただし、型制御やカプセル化制約はこのライブラリで既に実装されていた。
Pascalは見たことがあるから覚えていて、授業中に何度かTurboVisionを差し込むこともできましたが...。私の記憶では、Turbowijnをどうひねっても、非常に不愉快です。とにかく、出力はNorton Commanderだけで、すべてが非常に狭く専門的で、私の記憶が間違っていなければ、Pascal 6.0はまだOOPではありませんでした。
パスカルは見たことがあるので覚えていましたし、授業中に何度かTurbowijnを差し込むこともできましたが...。Turbowizhneをどうひねっても、Norton Commanderしか出力されないという、非常に不愉快な思い出です。すべてが非常に特殊で、私の誤解でなければ、Pascal 6.0にはまだOOPがありませんでした
確か、TurboVisionはまさに最初のOOPライブラリで（当時は思想のサポートが不完全でしたが、それでも）、Pascal 6.0に登場しました。
ウィキペディアを 調べると、どうも納得がいく。
私の記憶では、TurboVisionはまさに最初のOOPライブラリで、Pascal 6.0で登場しました（当時は思想のサポートが不完全でしたが、それでも）。
ウィキペディアで 調べました。 私の意見と一致しているようです。
5年後、私は自分でDelphiに行きましたが、Pascalは手続き型プログラミング言語として私の頭の中に残りました。
確か、TurboVisionは最初のOOPライブラリで（当時の思想のサポートは不完全でしたが、それでも）、Pascal 6.0に登場したものです
ウィキペディアで 調べましたが、どうも私と同じようです。
Pascalの本格的なOOPは、Delphiで初めて登場した。Turbo Visionは、Ms-DOSのテキストGUIのことだけを指していた。
PascalのフルOOPは、Delphiで初めて登場しました。Turbo Visionは、もっぱらMs-DOSのテキストGUIを対象としていた。
まあ、それは「サポートが不完全なまま」ということなんですが。6番目のパスカルは、「オブジェクトを持つパスカル」でした。それもそのはず、TurboVisionは純粋なウィンドウ型インターフェイスだったのです。まあ、だいたいピーターが持ってきたものですが。
実は、ピーターの創作はなかなか面白い。疑問を感じるのは、その適用性です。グローバルにアクセス可能なオブジェクトやコードの完全なカプセル化がないため、純粋な仮想インターフェイスのみで作業することで多くのバグを防ぎ、バグのサポートや修正に役立つということに一度も遭遇したことがありません。実は、Peterは「プログラマーの利便性に基づく」と正確に指摘しています。
すべての機能の配列に フルアクセス できる - 理論的には、インターフェースラッパー、制御や型変換、オブジェクトアクセスプロトコルに従うなどのオーバーヘッドがないため、実際に高い効率を達成することができる......。しかし、これらはすべて、プログラマー自身が記憶し、考慮しなければならないという事実だけで達成されるのである。
あらゆる意味でコンピュータに仕事を移さず、自分たちでやるということがわかったのです。ピーターさんは、暗記の巨人として、それに埋没することはない。でも、それ以外の人はかなりのストレスになるんじゃないかと思います。そして、何か大きなメリットを求めて、それに同意してしまうこともある。残念ですが、見当たりません。特にピーターは自動売買ではなく、手動売買に重点を置いているので。
覚えるコツは、思考が構造化されていることです。OOPのレンズを通してコードを見ることは必要ですが、OOPそのものを使うことはありません。これが私の仕事です。あなたはプログラムにOOPを搭載し、私は頭の中にそれを搭載しています。
だからこそ、OOPの良さも、それがないことの良さもわかるんです。そして、OOPの利点だけを得ることができます。
覚えるコツは、思考が構造化されていることです。OOPのレンズを通してコードを見ることは必要ですが、OOPそのものを使うことはありません。これが私の仕事です。あなたはプログラムにOOPを搭載し、私は頭の中にそれを搭載しています。
だからこそ、OOPの良さも、それがないことの良さもわかるんです。そして、OOPの利点だけを得ることができます。
それで思い出した。
だから、OOPのメリットと、OOPを持たないメリットを得ることができるんです。そして、OOPのメリットだけを得ることができるのです。
見たままを言うのは難しいですが、既成のクラスを、そのメソッドとフィールドをグローバルスコープに持ってきて（デプロイ）、アプローチを取得し、フィールドをカーネルとエンジンと呼んで取得すると...と言うことになりますね。は、ゼロから書くことはできても、修正することができない、管理しきれないコードを手に入れることになります。
ZSです。
なぜOOPは面白いのか？- なぜなら、プログラマーは常に新しい変数名を考える必要がないからです。- ベースクラスを作って、その時見たものを全部書いて終わり......。継承する必要はなく、クラスのインスタンスを作成し（クラスの配列でも可！）、オブジェクト（クラス）ごとに分割された変数を一度に取得すればよいのです ...少なくともOOPは実用的だし、実行速度も...。CPUのレジスタを直接扱うか、より高度な言語を使うか、通常は便利なようにすべてを書き込むのに十分な計算能力があり、十分でない場合はプロファイリングを開始し、問題のあるコードセグメントを書き換えます - これを行う人は多くありません。
見たままを言うのは難しいのですが、既製のクラスを取り出し、そのメソッドとフィールドをグローバルスコープに持ってくる（デプロイする）と、あなたのアプローチが得られ、そして、フィールドをカーネルとエンジンと呼んで得る...と言うことでしょう。は、ゼロから書くことはできても、修正することができない、管理しきれないコードを手に入れることになります。
ZSです。
なぜOOPは面白いのか？- なぜなら、プログラマーは常に新しい変数名を考える必要がないからです。- ベースクラスを作って、その時見たものを全部書いて終わり......。継承する必要はなく、クラスのインスタンス（クラスの配列でも可！）を作成し、オブジェクト（クラス）ごとに分割された変数を一度に取得すればよいのです．少なくともOOPは実用的だし、実行速度も...。プロセッサのレジスタを直接操作したり、より高度な言語を使用したり、通常は便利なようにすべてを書き込むのに十分な計算能力があり、もし十分な能力がなければ、プロファイリングを開始して問題のあるコード部分を書き直しますが、これを行う人は多くありません。
私がOOPに嫌悪感を抱くのは、コードの書き方が硬直的であることです。ご覧のように、私は大きなデータ表をまとめることが多いので、とても実用的だと思います。OOPでは、たくさんのルールに従わなければならないので、個人的にはとても窮屈に感じています。
要するに、違うOOPでプログラミングしているんです。私自身のことです。ルールはほとんどなく、自由度が高い。機能そのものは大きなブロックにまとめられ、データはカーネルで整理される。特別に構造まで考えているわけではありません。すべては自ら発展していくものです。直感的なレベルでは