PLOについての興味深い見解 - ページ 12

 
fxsaber:

習慣や構文の知識の問題であることは理解していますが、原作者である私がコードに入り込むのは非常に難しいと感じています。

残念ながら、FPスタイルでMQLを使うことはできないんです。簡単に説明すると、オファー条件(PammSet)があり、その条件を財務結果に変換する機能(AccountRecord)があるというアプローチである。どちらのタイプも不変であり、作成時に設定される。タスクは、オファーのセットを生成し、このセットの各要素をマッピング関数(Set1, Set2, Set3)を通じて財務結果と比較することである。重要な要素は,シーケンスの各要素にFunc<in, out>のような任意の関数を適用するSELECT関数である.

 

ジャック・フレスコ、FPとPLOについて


 
また、このFPは、関数ポインタを使う のと根本的にどう違うのでしょうか?
 
Dmitry Fedoseev:
また、関数へのポインタを 使うのと根本的にどう違うのでしょうか?

であり、FP構文がより便利であるというだけです。

をベースにしたコードアーキテクチャを採用するほど、便利です。

例えば、マウスがクリックされたときに実行されるタスクを受け取るブロックを作ることができます ....例えばGUIの場合。

そこで、呼び出しをリストにまとめて、実行するジョブを簡単に追加することができます。

Button1.MouseClickAdd(() => (ここにFunk();風の関数へのリンクがあります))

この場合、このような設定、すなわちタスクは、ユーザーが追加することができ、ユーザーはツールバーのコードを使用して、ボタンに対するアクションを設定することができます....

この場合、関数のバインディングはスコープから取得されます。つまり、クラスは何にでも追加することができます。つまり、関数の最終結果を追加するのではなく、この条件が発生したときに実行(呼び出し)される関数を追加しているのです。

 
Dmitry Fedoseev:
また、このFPは、関数ポインタを使う のと根本的にどう違うのでしょうか?

FPはラムダ計算の実装であり、命令型プログラミング(OOPを含む)はチューリングマシンの実装である。

 
Aleksey Nikolayev:

FPはラムダ計算の実装であり、命令型プログラミング(OOPを含む)はチューリングマシンの実装である。

理にかなっている)

 

フライとカツ」の議論をしているようです。

FPがOOPの素晴らしい代用品であるならば、上記の例ではなく、FPで実装されたGUIの例を見せてください

Кнопка1.MouseClickAdd(()=>(тут ссылка на нашу функцию в стиле Funk();))

が、ボタン、チェックボックス、スクロールバーなどの一例です。- はすべてFPで作られています。


しかし、FPが(手続き型スタイルから発展した)OOPの代替品であると議論することは、ホットとコールドの比較に過ぎないのではと思います。

 
Igor Makanu:

フライとカツ」の議論をしているようです。

FPがOOPの素晴らしい代用品であるならば、上記の例ではなく、FPで実装されたGUIの例を見せてください

が、ボタン、チェックボックス、スクロールバーなどの一例です。- はすべてFPで作られています。


しかし、FPが(手続き型スタイルから発展した)OOPの代替品であると議論することは、温故知新の比較であると思います。

ここでは、まさに一方が他方を妨げるのではなく、他方を補うのです。

また、必要であれば、タイクの構造を使って、OOPのようにFPですべてを作ることもできます - 非常に怪しい作業ではありますが
 
Alexandr Andreev:

そこで、一方が他方を邪魔することなく、他方を補う。

そうこなくっちゃ

そして、このスレッドの最初の投稿にある記事は、目的の点で全く異なる2つのプログラミングパラダイムを比較しようとしています。

 
Aleksey Nikolayev:

FPはラムダ計算の実装であり、命令型プログラミング(OOPを含む)はチューリングマシンの実装である。

徹底的な!これ以上追加することはないでしょう ))