記事"ユニバーサルEA: CUnIndicator と予約オーダーの使用 (その 9)"についてのディスカッション - ページ 4

 
Artyom Trishkin プロジェクトをやって いるんだ。

もちろん、当然のことながら、ヴァシリーの作品が選ばれたことに驚きはない。あなたは私の記事の意味と本質を少し誤解しているようだ。彼らはライブラリを作成するプロセスを説明しているのであって、すでに完成したものを使用するプロセスを説明しているのではない。開発に飛び込み、原理を理解したい人たち-彼らはそれを実行し、質問し、明確にし、学ぶ。そこに書かれていることをすぐに理解し、開発についていく人もいる。しかし、ここはそれを議論する場所ではない。ここはヴァシリーの仕事について議論する場所なのだ。

巨大な仕事を始めた私が、一夜にしてそれを放棄するとでも?もちろん、そんなことはない。発展の可能性はたくさんある。

私はあなたのライブラリを使おうとした。取引そのものには不十分だが、便利な機能がたくさんある。しかし、実用的な使い道が見当たりません。テストのスピードが大幅に落ちてしまいます。

 
Vasiliy Sokolov #:

こんにちは。ご意見ありがとうございます。最適な解決策は、UTEのコードを公開バージョン管理システム(GitやMTのもの)に置くことです。この場合、ユーザーは私のコードレビュー後にエラーを修正し、コードに追加変更/改良を加えることができます。このようなプロジェクト開発システムは、オープンソースに最適だと思います。

UTEそのものについては、主な機能が形成されていると思います。最も一般的な取引機能のほとんどをカバーしています。したがって、同じ方向でUTEを開発しても、根本的に新しいものは生まれない。しかし、データを扱うための機能的なフレームワークは、UTEの開発にグローバルな推進力を与えることができる。そのアイデアとは、オブジェクトスタイルでシステム構造を操作し、関数スタイルでコレクション(システムのものも含む)を操作することである。この場合、システムデータ型とユーザーデータ型の明確な区別はなくなり、その処理のためのクエリーはユーザー自身が「その場で」作成することになる(C#のLINQのようなもの)。残念ながら、言語の制約上、このフレームワークをワンツー・ベースで書くことはできないので、これはまだアイデアに過ぎない。

そしてマルチシンボル戦略ですが、作成できるのかどうか理解できません。2文字以上で機能するストラテジーを1つ。Strategy.mqhのコードから判断すると、動作するツールは常に1つです。