Canvasでクラウドソーシングのプロジェクトを作る - ページ 38

[Алексей Барбашин]

Реter Konow:
コアはマトリックスです。オブジェクトのすべてのプロパティが含まれています。

方法を選択することができます。しかし、長年のGUI開発の中で、開発したシステムと同等の機能アップを実現できる方法は他にはないと感じています。最大限のシンプルさと効率の良さが、完成度を高めています。

Peterさん、現在のバージョンに限らず、GUIを書いた経験や例はありますか？

他のパラダイムを完全否定しておきながら、自分のモデルがGUI実装に最適だと言い張る。賛否両論ある発言ですね。

[Maxim Kuznetsov]

描かれた直線の傾斜角、交点、楕円の比率を補正するインジケータを作る。アンカーポイントが未来に設定される一方で

2回の週末と血まみれのインディーズの日を経て...

追記／インターフェイスを描いている人は、トレーディングには全く関与していない感じです

[Алексей Барбашин]

Maxim Kuznetsov:

描いた直線の傾き角度、交点、楕円の比率を修正する表示器を作る。アンカーポイントを未来に設定したことで

2回の週末と血まみれのインディーズの日を経て...

追記／インターフェイスを描いている人は、トレードとは全く関係ないような気がします。

マックス あえて言えば、半分くらいはそうだと思います。トレーダーはプログラマーである必要はなく、プログラマーはトレーダーである必要はない。

[Алексей Барбашин]

あえて言うなら、Peterはmql以外ではプログラムを組まないということです。Java、Kotlin、Sharp、Python、C++など、現代版の言語はすべて、クラスを扱う知識を必要とします。1Cでも、固定オブジェクト型という形でクラスの体裁を整えている。しかし、これは余談に過ぎません。

私の考えでは、インターフェース構築の仕組みはこうあるべきだと思います。

CForm Форма = new CForm;
Интерфейс.Добавить(Форма);
CButton КнопкаBUY= new CButton;
КнопкаBUY.Заголовок = "BUY";
КнопкаBUY.ЦветФона = clrBlue;
КнопкаBUY.Позиция(7,20);
Форма.Добавить(КнопкаBUY);

つまり、インターフェイスの作成は宣言的に行うべきである。他のプログラマーがインデックスを参照しながらコントロールの プロパティの記述を追加していくなんて、想像もつきません......。

初心者はともかく、普通のプログラマーでも戸惑うことは間違いないでしょう。

[Aleksey Mavrin]

Алексей Барбашин:

あえて言うなら、Peterはmql以外ではプログラムを組まないということです。Java、Kotlin、Sharp、Python、C++など、現代版の言語はすべて、クラスを扱う知識を必要とします。1Cでも、固定オブジェクト型という形でクラスの体裁を整えている。しかし、これは余談に過ぎません。

私の考えでは、インターフェース構築の仕組みはこうあるべきだと思います。

つまり、インターフェイスの作成は宣言的に行うべきである。他のプログラマーがインデックスを参照しながら、ボードにプロパティの記述を 追加していくなんて、想像もつかない......。

初心者はともかく、一般のプログラマーでも戸惑うことが多いのではないでしょうか。

インデックスに依存する要素やプロパティが多ければ問題ないし、その逆も然りで、一つ一つを参照しながらごちゃごちゃ書くのは大変だ。

[Реter Konow]

Roman:

行列はループの入れ子であり、ループの入れ子は時間である。皮肉ではなく、論理的に推論しているだけです。

そうですね。宇宙のあらゆるものには時間がかかる）。

[Реter Konow]

Алексей Барбашин:

1.Peterさん、次のようになります。コアは、要素のプロパティのグローバル行列、要素の値のグローバル行列、依存関係のグローバル行列、ピクチャのグローバル行列から構成されています...。

2.さらに特性を追加する必要がある場合は、行列の次元が増加する。

3.セルには名前がないため、プロパティは厳密にインデックスによってアクセスされる。

少なくともフィールド名には構造体でアクセスできる。

ピーター、あなた...ジャイアント...

私などは、このように捉えています（簡略化）。

4.事実上の「クラス」は、グローバル配列の中の特定の文字列であり、より「人間的」な顔を持っています。クラスは、インデックスではなく名前でアクセスできる理解しやすいプロパティのセットを持つ、独自のデータオブジェクトを作成するように設計されています。クラスは普遍的な型コンストラクタに過ぎない。

そこで、ほとんどすべてのコントロールが持っている、最も一般的なプロパティを含む基本的なコントロールを作成します。

それを元に特殊なオブジェクトを作ることができます。

つまり、後続の各コントロールタイプは、ベースタイプに必要なプロパティを追加するだけである。

そして、先ほど書いたように、基本的なプロパティはベースコントロールに格納されているので、コントロールのカーソルを「打つ」というトラバースは、CControlという 一つのデータ 型をチェックすることで行われるのです。目的のオブジェクトを見つけると、プログラムはすぐにそのオブジェクトのプロパティにアクセスできます。プログラムポイントはすでにオブジェクト自体にあるので、ちょうどループの中でプログラムが目的の配列行にいるのと同じです。

1.コアは1つのグローバルマトリックスです。二次元です。コアは、マークアップ言語がどのウィンドウと要素を作成する必要があるかを記述したファイルを読み込む特別な機能によって構築されます。

2.いいえ、行列の次元数は一定です。2次元しかない。

3.カーネルに含まれるオブジェクトのプロパティは順序付けされている。それぞれにインデックスがあります。インデックスはdefineによって命名される。オブジェクトのプロパティの数が増えると、行列の幅が広がります。その成長を抑制し、中の物をコンパクトにする方法があるのです。

4.クラスは、オブジェクトの記述としては良いのですが、メカニズム（コードのこと）はカーネルを使った方が効率的に動きます。とにかく、どうでもいいんです。誰のニーズにも合う

オブジェクトのプロパティの記述と保存が分散している（主なものはベースクラス、その他は子孫クラス）ため、アクセスや取り扱いが複雑になる。さらに視認性の制限、アクセス修飾、異国語などが加わると、メカニズムだけでなく、開発プロセスも大幅に短縮されます。ただし、これはイミフです。

[Алексей Барбашин]

Реter Konow:
1.コアは1つのグローバルマトリックスです。二次元です。コアは、マークアップ言語がどのウィンドウと要素を作成する必要があるかを記述したファイルを読み込む特別な機能によって構築されます。

2.いいえ、行列の次元数は一定です。2次元しかない。

3.カーネル内のオブジェクトのプロパティは順序付けされている。それぞれにインデックスがあります。インデックスはdefineによって命名される。オブジェクトのプロパティの数が増えると、行列の幅が大きくなる。その成長を抑制し、中の物をコンパクトにする方法があるのです。

4.クラスは、オブジェクトの記述としては良いのですが、メカニズム（コードのこと）はカーネルを使った方が効率的に動きます。とにかく、どうでもいいんです。誰のニーズにも合う

オブジェクトのプロパティの記述と保存が分散している（主なものはベースクラス、その他は子孫クラス）ため、アクセスや取り扱いが複雑に なる。さらに視認性の制限、アクセス修飾、エイリアン言語などが加わると、機構だけでなく開発プロセスも大幅に短縮されます。ただし、これはイミフです。

全然複雑じゃないのが、授業の良さであり、力なんです。元のオブジェクトの機能をベースに、次のオブジェクトがそれぞれ機能を構築していく。その結果、基本的な機能（フォーカス、クリック、要素外、ドラッグ＆ドロップ、描画）は、すべて基本オブジェクトをベースに実装されています。さらに開発や修正、新しいコントロールの開発など、これらはすべて基本機能に影響を与えず、例えば言語のレベルで作成されるため、ライブラリの「核」となります。 この場合、オブジェクトは、特定のプロパティに必要なデータ型だけを 持つことになる。

"コアは、ファイルを読み込む特殊な機能で作られていて、そこにはどんなウィンドウや要素を作らなければならないかが、マークアップ言語で書かれています。"- は、まさにすずしい。 つまり、すべてのプロパティを格納するマトリックスがあり、さらに、プロパティを含むマトリックスの読み取り方法を正確に指定するマークアップファイルがある...。「インデックスはdefineを介して命名 される」 - 各インデックスはdefineにハードワイヤーされています。ランダムに余分なフィールドを挿入すると、結果的にプロパティがずれることになります。"オブジェクトのプロパティの数が増えると、行列の幅が大きくなる" - 次元と言ったのはそういう意味です（私のミスで、この用語を間違って適用してしまいました）。データオブジェクトをクラスとして作成することで、これらの煩雑さを回避することができます。そしてこれが、本当は必要のない本当の複雑さなのです。しかし、私たちは、後でうまく克服するために、自分たちで複雑な状況を作り出す方法を知っています。

しかも、階層的なクラスを作る必要がなく、全く使う必要がない。しかし、不要なデータスレッドを取り除くために構造体を使用することは合理的です。IMHO

Peterさん、あなた流のGUIライブラリを見事に作り上げましたね。しかし、もしこれを出版する予定があるなら、やはりすべてを別の技術に設計し直す価値があるのではないでしょうか。私はそのお手伝いをし、一歩一歩、あなたのライブラリーのすべての力を新しい方向へ移していく準備ができています。

[Реter Konow]

Алексей Барбашин:

これ以上複雑なことはない。それが授業の美しさであり、力なのです。元のオブジェクトの機能をベースに、次のオブジェクトがそれぞれ機能を構築していく。その結果、すべての基本機能（フォーカス、クリック、要素外、ドラッグ＆ドロップ、描画）は、基本オブジェクトをベースに実装されています。さらに開発や修正、新しいコントロールの開発など、これらはすべて基本機能に影響を与えず、例えば言語のレベルで作成されるため、ライブラリの「核」となります。 この場合、オブジェクトは、特定のプロパティに必要なデータ型だけを 持つことになる。

"コアは、ファイルを読み込む特殊な機能で作られていて、そこにはどんなウィンドウや要素を作らなければならないかが、マークアップ言語で書かれています。"- は、まさにすずしい。 つまり、すべてのプロパティを格納するマトリックスがあり、さらに、プロパティを含むマトリックスの読み取り方法を正確に指定するマークアップファイルがある...。データオブジェクトをクラスとして作成することで、このような複雑さを回避することができます。そして、これらは本当に必要ない複雑なものなのです。私たちは、後でうまく克服するために、いかに自分で複雑な状況を作り出すかを知っています。

しかも、階層的なクラスを作る必要がなく、全く使う必要がない。しかし、不要なデータスレッドを取り除くために構造体を使用することは合理的です。IMHO

Peterさん、あなた流のGUIライブラリを見事に作り上げましたね。しかし、もしこれを出版する予定があるなら、やはりすべてを別の技術に設計し直す価値があるのではないでしょうか。私はそのお手伝いをさせていただき、一歩一歩、ライブラリーのすべての力を新しい方向へ動かしていきたいと考えています。

あのね、自他の解決策を実行することについては、ここで散々議論してきたので、もう飽きたんだよ。))ただ、本当に疲れるんですよ。私の思考はマトリックスに、他の人の思考はクラスに適応している...。これでは槍を折る価値もない。

私は一般的に、ルールを変えたり簡略化したり、一般的なコースから外れたり、誰かのものよりも自分のものを主張したりする傾向があります。あなたは私を変えることはできません。

ご提案ありがとうございます。GUI開発では、自分の道を進むことができます。もう自分のやり方でやったので、違うスタイルで繰り返しても意味がないと思っています。マークアップ言語があり、ビスエディターまで数ステップ、公開まで1週間ほど。タスクバーのやり直しや細かいバグの摘出が残っています。そして、私の作品に感想を述べていただきます。皆さんのお役に立てれば幸いです。

ZS.出版後は、解答の詳細をお伝えすることができますので、授業でアナログを作る際の参考になるかもしれませんね。

[Алексей Барбашин]

Реter Konow:
自他解の実装について、ここで散々議論して、もう飽きたよ。))ただ、本当に疲れるんです。私の思考はマトリックスに、他の人の思考はクラスに適応している...。槍を折る価値もない。

私は一般的に、ルールを変えたり簡略 化したり、一般的なコースから外れたり、誰かのものよりも自分のものを主張したりする傾向があるようです。あなたは私を変えることはできません。

ご提案ありがとうございました。GUI開発では、自分の道を進むことができます。もう自分のやり方でやったので、違うスタイルで繰り返しても意味がないと思っています。マークアップ言語があり、ビスエディターまで数ステップ、公開まで約1週間。タスクバーのやり直しや細かいバグの摘出が残っています。そして、私の作品に感想を述べていただきます。皆さんのお役に立てればと思います。

あなたの場合は簡略化ではなく、本当に複雑化していますね。IMHO