リアクティブプログラミングとは何ですか？ウィキペディアの記事は、これがデータストリームと変化の拡散に焦点を当てたプログラミングパラダイムであることを教えています。この定義は、技術的には正しい（まだ！）が、このすべての背後に実際に隠されているものについて非常に曖昧な考えを与えます。一方、反応性の概念は単純で自然であり、次の例で説明するのが最善です。

私たちは皆、Microsoft Excelなどのスプレッドシートを使用したことがあります。テーブルのセルに、ユーザーは他のセルを参照する数式を記述できます。それらのいずれかの値が変更されると、数式が再計算され、セルが自動的に更新されます。さらに、私たちのセルが他の数式に参加している場合、それらは自動的に再カウントされ、など、連鎖反応の発生に似たプロセスになります。したがって、これがリアクティブプログラミングの主なアイデアです。

リアクティブプログラミングのトピックに関する多くの記事（ 1、2、3、4など）が既にありました。主に、JavaScriptのbacon.js 、JavaのJavaRxなどのライブラリの形式で、 FRPバージョンのリアクティブを説明しています。。この記事では、 Jancy言語でのリアクティブプログラミングの実装とアプリケーションについて説明します。この資料は、Jancy言語を聞いたことがなく、何も書かなくても読むのが面白いでしょう。なぜなら、後ほど命令型言語からの反応性へのかなり珍しいアプローチを示すからです。

いずれの既存のリアクティブライブラリを使用する場合でも、 Observableパターンが実装の鍵となります。実際、変更を「広める」ためには、少なくともそれらに関する通知を受け取る必要があります。観測可能なエンティティは、通常2つのプリミティブに分割されます（ライブラリごとに異なる呼び出し方が行われます）。

イベントのストリーム（EventStream / Observable / Event / Stream）;
プロパティ（プロパティ/動作/属性）-時間とともに変化する値。

FRPでは、これはすべて関数プログラミングの要素を要求します。そのようなプリミティブから複雑な構造を構築するには、map、reduce、filter、combineなどの高次関数が使用されます。（元のフローとイベントを「変更」する代わりに）セカンダリフローとイベントを生成します。オブザーバブルと機能から得られるコンポートは、理解して習得するのがそれほど難しくなく、同時にコンポーネント間の依存関係を宣言形式で表現できます。これは、複雑なユーザーインターフェイスや分散非同期システムのプログラミングに最適です。改善すべき点はありますか？

問題

最初の問題はこれです。コンパイラでオブザーバブルを使用せずに、ライブラリレベルで反応性が実装されている場合、Excelで自動的に再計算された式は達成不可能な理想のままです。代わりに、いくつかのマップを手動で実行し、オブザーバブルで結合する必要があります-数式のロジックが複雑になるほど、onValue / assignで値を適切な場所に書き込みます。

おそらく、オープンソースのJavaScriptコンパイラであるFlapjaxは、Excelに似た式に最も近いものになったでしょう（この種のプロジェクトが他にもある場合は、コメントに書いてください）。 FlapjaxではBehavorと呼ばれるタイプ2オブザーバブルは、式で任意に組み合わせて、新しいBehavorを出力できます。

魔法の鍋

しかし、リアクティブライブラリとFlapjaxの両方に固有の別の基本的な問題があります-これは「ポットを調理しない」問題です。イベント、プロパティ、および相互サブスクリプションのフローからインフラストラクチャを作成した後、インフラストラクチャは独自の生活を始めます。データは流れ、変換されます。私たちが尋ねたように、必要なアクションはさまざまなonValueとonCompletedで実行され、すべてが素晴らしいです。それで、今どうやって止めますか？すべてのルートオブザーバブルを調べて、手動でイベントの発行を停止しますか？あまり美しくありません。しかし、すべてを停止するのではなく、リアクティブディペンデンシーグラフの一部のみを停止する必要がある場合はどうでしょうか。私たちのオブザーバブルの大部分は、暗黙的なマップ/結合/フィルター結果の形で存在しますか？

少し異なる方法で再定式化すると、既存のリアクティブライブラリの問題の1つは、（主に機能的な方向性のために）観測可能なオブジェクトの1レベル構造を生成することです！

ただし、批判は、何らかの代替手段を提供するよりも常に簡単です。それでは、反応性に関してジャンシーには何がありますか？

オブザーバブルを使用した数式の Excelのような自動再計算 -プログラマが選択した場合のみ。
オブザーバブル間で依存関係クラスターをグループ化し、クラスター内のすべてのサブスクリプションを一度に開始および停止する機能。

次のようになります。

reactor TcpConnectionSession.m_uiReactor () { m_title = $"TCP $(m_addressCombo.m_editText)"; m_isTransmitEnabled = m_state == State.Connected; m_adapterProp.m_isEnabled = m_useLocalAddressProp.m_value; m_localPortProp.m_isEnabled = m_useLocalAddressProp.m_value; m_actionTable [ActionId.Connect].m_text = m_state ? "Disconnect" : "Connect"; m_actionTable [ActionId.Connect].m_icon = m_iconTable [m_state ? IconId.Disconnect : IconId.Connect]; m_statusPaneTable [StatusPaneId.State].m_text = m_stateStringTable [m_state]; m_statusPaneTable [StatusPaneId.RemoteAddress].m_text = m_state > State.Resolving ? m_remoteAddress.getString () : "<peer-address>"; m_statusPaneTable [StatusPaneId.RemoteAddress].m_isVisible = m_state > State.Resolving; }

これは、TCP接続IOニンジャターミナルセッションのソースコードからの抜粋です。ご想像のとおり、このコードはステータスの変更、コンボボックス内のテキストなどを使用してUIを更新します。

そして今、それがどのように機能するかについて。

一般計画

まず、混乱を避けるために、用語に同意します。

Jancyのプロパティには一般的に受け入れられている（非反応）定義があります-これは変数/フィールドのように見えるギズモですが、アクセサー関数でアクションを実行できます。

マルチキャスト （マルチキャスト）とイベント （イベント）は、関数へのポインターを蓄積し、それらを一度に呼び出すために使用されます（マルチキャストとイベントの違いについては少し後で）。

Jancyでは、コンパイラレベルで観察できるのは「バインド可能なプロパティ」、つまり onChangedイベントを通じて変更を通知できるプロパティ。

Jancyの反応性とは異なり、Jancyの反応性は、「サブスクライブ」、新しいオブザーバブルの暗黙的な生成などの副作用があるため、オブザーバブルが使用されている場所に「あまりにもスマート」になりません。彼女は角に立って尋ねません。命令型スタイルでバインディングプロパティにアクセスするのは、通常の変数にアクセスするよりも高くありません。

これは、上記のExcelの事後再集計にどのように適合しますか？ リアクティブコードの特別なゾーンが提供されているため、Jancyのリアクティブおよび命令型の原則の競合のない共存が可能です。 原子炉 一連の命令の代わりに、リアクターはExcelのような式-式で構成されます。式はそれぞれバインディングプロパティを使用する必要があります。リアクタ内では、バインディングプロパティは「反応的に」動作します。

したがって、Jancyのリアクティブプログラミングの基本的な構成要素は、 イベント 、 関連するプロパティ、およびリアクターです。これらのレンガを詳しく見てみましょう。

マルチキャストとイベント

Jancy のマルチキャストは、コンパイラーによって生成される特別なクラスであり、関数へのポインターを蓄積し、それらを一度に呼び出すことができます。マルチキャスト宣言は関数宣言に非常に似ていますが、このマルチキャストに格納される関数ポインターのタイプを明確に決定する必要があるため、驚くことではありません。

 foo (int x); bar ( int x, int y ); baz () { multicast m (int); // normal (fat) multicast intptr fooCookie = m.add (foo); m += bar ~(, 200); // capture the 2nd argument m (100); // <-- foo (100); bar (100, 200); m -= fooCookie; m (300); // <-- bar (300, 200); m.clear (); }

マルチキャストクラスのメソッドの詳細

たとえば、単純なマルチキャストを定義します。

 multicast m (int);

上記の例で生成されるマルチキャストクラスには、次のメソッドがあります。

 void clear (); intptr set (function* (int)); // returns cookie intptr add (function* (int)); // returns cookie function* remove (intptr cookie) (int); function* getSnapshot () (int); void call (int);

setおよびaddメソッドは、removeメソッドで使用できる特定の整数Cookieを返し、マルチキャストからポインターを効果的に削除します。

一部のメソッドには、演算子の形式のエイリアスもあります。

 multicast m (); m = foo; // same as m.set (foo); m += bar; // same as m.add (bar); m -= cookie; // same as m.remove (cookie); m = null; // same as m.clear (); m (10); // same as m.call (10);

マルチキャストは、マルチキャストに蓄積されたすべてのポインターを呼び出す関数へのポインターにキャストできます。しかし、あいまいさがあります。つまり、そのようなキャストは「ライブ」（ライブ）なのかスナップショットなのか。つまり、関数へのポインターを作成した後に元のマルチキャストを変更した場合、このポインターは変更を確認する必要がありますか？

あいまいさを解決するために、マルチキャストにはスナップショットを返すgetSnapshotメソッドが用意されています。同時に、キャスト演算子はライブポインターを提供します。

 foo (); bar (); baz () { multicast m (); m += foo; function* f1 () = m.getSnapshot (); function* f2 () = m; m += bar; f1 (45); // <-- foo (); f2 (55); // <-- foo (); bar (); return 0; }

Jancyのイベントは、アクセス制限のあるマルチキャストへの特別なポインターです。追加と削除のみを実行できます。

 foo () { multicast m (int); event* p (int) = m; p += bar; // OK p (100); // <-- error, 'call' is inaccessible }

「イベント」タイプの変数またはフィールドを宣言すると、 デュアルタイプが作成されます。「フレンド」の場合、このタイプはマルチキャスト修飾子が使用されたかのように動作し、「ストレンジャー」の場合、追加および削除を除くすべてのメソッドの呼び出しが禁止されたイベントです。

Jancyのデュアルタイプの詳細

Jancyのアクセスモデルと他のほとんどのオブジェクト指向言語の主な違いは、アクセス指定子の数が2つのpublicとprotectedに削減されていることです。

一方では、これにより開発者はだれが何にアクセスできるかを決定する際の柔軟性が大幅に低下します。一方、この単純化されたモデルを使用すると、全員を「友人または敵」に明確に分割することができます。これにより、 二重修飾子の可能性が開かれます。「友人」と「見知らぬ人」に対して異なる意味を持つ修飾子、およびそれらの助けを借りて作成されたデュアルタイプ 。

したがって、Jancyでは、個々の名前空間Aごとに、残りの世界は「私たち」と「エイリアン」の2つのカテゴリに分類されます。名前空間A自体に加えて、次のものは「インサイダー」に属します。

Aから継承したクラスまたは構造の名前空間。
友達として宣言された名前空間
A名前空間に関する子。
拡張機能（拡張ネームスペース）A.

残りはすべて「見知らぬ人」です。「所有者」は名前空間のパブリック（パブリック）メンバーと保護（保護）メンバーの両方にアクセスできますが、「ストレンジャー」はパブリックメンバーのみにアクセスできます。さらに、「友人」または「見知らぬ人」のグループに所属すると、デュアルジャンシー修飾子の意味が変わります。

読み取り専用デュアル修飾子を使用して、読み取り専用アクセスをエレガントに整理できます。 Jancyの開発者は、アクセス制御を目的とする単純なgetterを作成する代わりに、読み取り専用修飾子を使用してフィールドを宣言できます。「友人」の場合、読み取り専用修飾子は表示されません。「見知らぬ人」の場合、読み取り専用はconstとして扱われます。

 class C1 { int readonly m_progress; foo () { m_progress += 25; // OK // ... } } bar (C1* c) { c.m_progress = 100; // <-- error, cannot write to 'const' location }

このアプローチの主な利点は、コードをより短く、より自然にすることです。単純化、したがって、ダミーのゲッターを分析して捨てる必要のないオプティマイザーの加速は、副次的効果と呼ぶことができます。

Jancyの2番目の二重修飾子はeventです。イベントの所有者は、すべてのサブスクライバーに電話をかけたり、リストをクリアしたりする機能など、彼を完全に制御する必要があります。イベントクライアントは、サブスクライバーの追加または削除のみが可能です。「友人」の場合、イベント修飾子を持つフィールドは、対応する引数の署名を持つマルチキャストと同じように機能します。「ストレンジャー」の場合、このフィールドはマルチキャストメソッドへのアクセスを制限します。追加と削除の呼び出しのみが許可されます。呼び出し、設定、クリア、getSnapshot、および関数ポインターへのキャストは禁止されています。

 class C1 { event m_onCompleted (); // dual type bool work () { // ... m_onCompleted (); // OK, friends have multicast-access to m_onComplete return true; } } foo () { C1 c; c.m_onCompleted += completionFunc; // ok, aliens have event-access to m_onComplete c.m_onCompleted (); // <-- error, 'call' is inaccessible c.m_onCompleted.clear (); // <-- error, 'clear' is inaccessible }

プロパティ

プログラミング言語のコンテキストでは、 プロパティはデータのように見え、動作するものですが、読み取りおよび書き込み時に追加のアクションを実行できます。偽りの謙虚さなしに、Jancyはこれまでの形、色、サイズのプロパティの最も完全な実装を提供します。

詳細と例

定義

読み取りおよび書き込み中にアクションを実行する関数はアクセサーと呼ばれます。プロパティを読み取るためのアクセサーはゲッターと呼ばれ、レコードはセッターと呼ばれます。

Jancyの各プロパティには、1つのゲッターと、オプションで1つ以上の（オーバーロードされた） セッターがあります（つまり、Jancyには書き込み専用のプロパティはありません）。セッターがオーバーロードされている場合、特定のセッターの選択は、オーバーロードされた関数が選択されるのと同じルールに従って、プロパティへの値の割り当て中に行われます。

プロパティにセッターがない場合、const（プロパティ）と呼ばれます。他のプログラミング言語では、セッターなしのプロパティは通常読み取り専用と呼ばれますが、Jancyにはconstとreadonlyの概念が共存するため（読み取り専用は二重修飾子です）、確立された定義を何らかの方法で再定義する必要があります。そのため、Jancyでは、セッターのないプロパティはconstプロパティです。

シンプルなプロパティ

セッターがオーバーロードされていない単純なプロパティ（ほとんどの実用的なタスクは要約）の場合、最も自然な形式の宣言が提案されます。

 int property g_simpleProp; int const property g_simpleConstProp;

この形式は、インターフェイスの宣言に理想的です。または、開発者が宣言とメソッドの実装のC ++スタイルを好む場合に最適です。

 int g_simpleProp.get () { // ... } g_simpleProp.set (int x) { // ... } int g_simpleConstProp.get () { // ... }

発表の完全な形式

任意の複雑さのプロパティ（つまり、オーバーロードされたセッター、データフィールド、補助メソッドなどのプロパティ）には、完全な形式の宣言があります。

 property g_prop { int m_x = 5; // member field with in-place initializer int get () { return m_x; } set (int x) { m_x = x; update (); } set (double x); // overloaded setter update (); // helper method }

インデックス可能なプロパティ

Jancyは、インデックス可能なプロパティもサポートしています。配列のセマンティクスを持つプロパティ。このようなプロパティのアクセサは、追加のインデックス引数を受け入れます。ただし、実際の配列とは異なり、プロパティのインデックス引数は整数である必要はなく、厳密に言えば、「インデックス」の意味を持つ必要はありません。その使用は開発者によって完全に決定されます。

 int indexed property g_simpleProp (size_t i); property g_prop { int get ( size_t i, size_t j ); set ( size_t i, size_t j, int x ); set ( size_t i, size_t j, double x ); } foo () { int x = g_simpleProp [10]; g_prop [x] [20] = 100; }

自動取得プロパティ

ほとんどの場合、ゲッターはプロパティの現在の値が格納されている変数またはフィールドの値を返すだけでよく、プロパティ自体の動作のロジックはセッターで具体化されます。明らかに、このような取るに足らないゲッターの作成はコンパイラーに転送できます-これがJancyのしたことです。 autogetプロパティの場合、コンパイラはデータを格納するゲッターとフィールドを自動的に作成します。さらに、コンパイラは可能な限りゲッターをバイパスして、フィールドへの直接アクセスを生成します。

 int autoget property g_simpleProp; g_simpleProp.set (int x) { m_value = x; // the name of a compiler-generated field is 'm_value' } property g_prop { int autoget m_x; // declaring an autoget field makes the whole property autoget set (int x); set (double x); }

プロパティの動作の特別なロジックがゲッターに埋め込まれ、ダミーのセッターがデータをメモリセルに挿入するだけの場合の逆の状況はまれであり、特別な構文の作成に値しません。

リアクティブプログラミングに適用される最も興味深いのは、 関連するプロパティです。サブスクライバーに変更を通知できるプロパティ。ご想像のとおり、Jancyはマルチキャスト/イベントメカニズムを使用してバインディングプロパティを実装します。

 int autoget bindable property g_simpleProp; g_simpleProp.set (int x) { if (x == m_value) return; m_value = x; m_onChanged (); // the name of a compiler-generated bindable event is 'm_onChanged' } property g_prop { autoget int m_x; bindable event m_e (); // declaring a bindable event makes the whole property bindable set (int x); set (double x); }

関連するプロパティの変更について通知するイベントにアクセスするには、 bindingof演算子を使用します。

 onSimplePropChanged () { // ... } foo () { bindingof (g_simpleProp) += onSimplePropChanged; g_simpleProp = 100; // bindable event is going to get fired }

Jancyは、完全にコンパイラーが生成したアクセター（ゲッターとセッターの両方）とのプロパティーのバインディングもサポートしています。これらの変性プロパティは、バインド可能データと呼ばれます。それらは単一の目的-変更の瞬間をキャッチする-を提供し、単純な観察可能な変数/フィールドとして機能できます：

 int bindable g_data; onDataChanged () { // ... } foo () { bindingof (g_data) += onDataChanged; g_data = 100; // onDataChanged will get called g_data = 100; // onDataChanged will NOT get called }

原子炉

Jancy のリアクターは、リアクティブコードゾーンです。すべての事後依存性と暗黙的なサブスクリプションは、リアクター内にローカライズされます。

外部では、reactorは通常の関数のように見えますが、広告がリアクター修飾子を指定している点が異なります。関数とは異なり、各リアクターは、リアクターを開始および停止できる開始と停止の2つのパブリックメソッドを持つ特別なリアクタークラスの変数またはフィールドを作成します。通常の関数の本体を構成するステートメント（ステートメント）の代わりに、リアクターの本体は一連の式で構成され、各式はその右側の関連するプロパティを使用する必要があります。

 State bindable m_state; reactor m_uiReactor () { m_isTransmitEnabled = m_state == State.Connected; m_actionTable [ActionId.Disconnect].m_isEnabled = m_state != State.Closed; // ... }

起動時に、リアクターは依存関係グラフを作成し、すべての「制御」プロパティのすべての関連イベントにサブスクライブします。それらのいずれかが変更されると、すべての依存式が再計算されます（もちろん、他のプロパティで雪崩のような変更を引き起こす可能性があります）。

循環依存関係をどうしますか？

現時点では、循環依存関係の更新は単に無視されます。つまり、Pの制御プロパティのいずれかが変更され、リアクターで式の再計算が行われ、その結果、このPのプロパティの値が変更された場合、この繰り返しの変更はリアクターでの計算の再帰的な開始を引き起こしません。

将来的には、おそらく、深さがまだ超過している場合、リアクターには許容される再帰の深さと回復戦略の設定があります（エラーでリアクターを無視/停止する/コールバックを呼び出すなど）

リアクティブ式に加えて、リアクターでは、直感的な構文で、任意のイベントとその処理コードをリンクできます。このために、 イベントのデザインが提供されます。このアプローチにより、UIに対して従来のイベントアプローチを使用できると同時に、イベントを手動でサブスクライブする必要がなくなります。

 reactor m_uiReactor () { onevent m_startButton.m_onClicked () { // handle start button click... } onevent (bindingof (m_userEdit.m_text), bindingof (m_passwordEdit.m_text)) () { // handle login change... } // ... }

シャットダウンすると、リアクターはサブスクライブされているすべてのイベントからサブスクライブされません（リアクターがクラスのメンバーである場合、シャットダウンは親オブジェクトの破壊時に自動的に発生します）。したがって、開発者は、リアクティブアプローチを使用する場所（リアクターゾーン）といつ（開始/停止）を詳細に決定することができます。暗黙のサブスクリプションはすべてまとめられ、秘跡的な「調理しない」ポットを作るのは非常に簡単です。

 m_uiReactor.stop ();

この場合、もちろん、同じバインディングプロパティと他のイベントを使用する複数のリアクターが存在する可能性があります-依存関係を特定のクラスターに論理的にグループ化するために必要な場合。

すべて一緒に

そのため、美しいユーザーインターフェイスフレームワークを組み立てて、リアクティブスタイルで使用するために、すべてのキューブがあります。

複数のUIクラス

 class Widget { bitflag enum SizePolicyFlag { Grow, Expand, Shrink, Ignore, } enum SizePolicy { Fixed = 0, Minimum = SizePolicyFlag.Grow, Maximum = SizePolicyFlag.Shrink, Preferred = SizePolicyFlag.Grow | SizePolicyFlag.Shrink, MinimumExpanding = SizePolicyFlag.Grow | SizePolicyFlag.Expand, Expanding = SizePolicyFlag.Grow| SizePolicyFlag.Shrink | SizePolicyFlag.Expand, Ignored = SizePolicyFlag.Shrink | SizePolicyFlag.Grow | SizePolicyFlag.Ignore } protected intptr m_handle; SizePolicy readonly m_hsizePolicy; SizePolicy readonly m_vsizePolicy; setSizePolicy ( SizePolicy hpolicy, SizePolicy vpolicy ); bool autoget property m_isVisible; bool autoget property m_isEnabled; } opaque class Label: Widget { bitflag enum Alignment { Left, Right, HCenter, Justify, Absolute, Top, Bottom, VCenter, } char const* autoget property m_text; int autoget property m_color; int autoget property m_backColor; Alignment autoget property m_alignment; Label* operator new (char const* text); } opaque class Button: Widget { char const* autoget property m_text; event m_onClicked (); Button* operator new (char const* text); } opaque class CheckBox: Widget { char const* autoget property m_text; bool bindable property m_isChecked; CheckBox* operator new (char const* text); } opaque class TextEdit: Widget { char const* property m_text; TextEdit* operator new (); } opaque class Slider: Widget { int autoget property m_minimum; int autoget property m_maximum; int bindable property m_value; Slider* operator new ( int minimum = 0, int maximum = 100 ); }

原子炉からの使用

 Slider* g_redSlider; Slider* g_greenSlider; Slider* g_blueSlider; int bindable g_color; Label* g_colorLabel; CheckBox* g_enablePrintCheckBox; TextEdit* g_textEdit; Button* g_printButton; int calcColorVolume (int color) { return (color & 0xff) + ((color >> 8) & 0xff) + ((color >> 16) & 0xff); } reactor g_uiReactor () { g_color = (g_redSlider.m_value << 16) | (g_greenSlider.m_value << 8) | (g_blueSlider.m_value); g_colorLabel.m_text = $"#$(g_color;06x)"; g_colorLabel.m_backColor = g_color; g_colorLabel.m_color = calcColorVolume (g_color) > 0x180 ? 0x000000 : 0xffffff; g_textEdit.m_isEnabled = g_enablePrintCheckBox.m_isChecked; g_printButton.m_isEnabled = g_enablePrintCheckBox.m_isChecked; onevent g_printButton.m_onClicked () { printf ($"> $(g_textEdit.m_text)\n"); } }

ハブロブスク市民の皆様は、当社のコンパイラのライブページに招待され、ダウンロード、インストール、またはビルドを行うことなく、Jancyの事後対応能力をテストできます。

Jancyのソースコードをダウンロードして収集/調査したい人は、ダウンロードページからこれを行うことができます。ちなみに、samples / 02_dialogフォルダーには、すぐ上のQTウィジェットに反応性を掛ける例があります。

そして、Jancyの実際のアプリケーションとそのリアクティブ機能は、プログラム可能なターミナル/スニファーIO Ninjaで見ることができます。

Jancyのリアクティブユーザーインターフェイスプログラミング

問題