こんにちは同僚！
前の記事で、 NWFSの一般的な問題について話しましたが、この記事では、このトピックを開発し、NWFSの問題をより具体的に示したいと思います。
重要なアイデア ： NWEPには2つの重要な問題があります：劣ったオブジェクトパラダイムと時期尚早のタイピングです。 下位オブジェクトのパラダイムは、型指定されていないオブジェクト構成の概念を定義しません（構成は、あらゆるパラダイムの重要な要素です）。 早すぎるタイピングは、抽象概念のセマンティクス（セマンティック抽象化）を制限します。
下位オブジェクトのパラダイム
オブジェクトパラダイムは、基礎となるメカニズムを明示的に定義しません。 どのパラダイムでも以下を決定する必要があります。
- 抽象化のプリミティブ -パラダイム思考スタイルを定義し、モデリングの基本要素です。
- プリミティブの構成 -任意の複雑さのシステム（モデル）を記述できます。 コンポジション自体もプリミティブでなければなりません。
- 集約関係は、構成内のプリミティブをリンクする抽象的なメカニズムです。 プリミティブは、外部の相互作用でもまったく同じメカニズムを発揮します。
- グローバル状態 -どこ（どのようにではありません！）システムの抽象的な（観察された）状態がローカライズされます。 このプロパティは、計算アーキテクチャの結果としてのパラダイムではありません。 モデルの実行結果は、最も一般的な意味での状態の変化によってのみ検出できます。
基本的に、 パラダイムは型付けされていない形式で定義されます。 パラダイムを使用するには（このパラダイムに基づいたPLの使用と混同しないでください）、タイピングは必要ありません。 パラダイムは、モデルを構築する方法とメカニズム（つまり、1つ以上の構成）のみを決定する必要があります。
さらに重要なことは、シミュレートされたシステムが複雑であるため、プリミティブではなく構成がシミュレーションの「ブリック」であることです。 構成は純粋な意味の抽象化であり 、型バインディングやその他の「リソース」はありません。 セマンティック抽象化は、その名前、さらには任意の形式の名前、単語またはフレーズによってのみ定義される概念です。
たとえば、機能的パラダイムはこれらの特性を完全に満たします（手続き型/命令型パラダイムでも同じことが言えます）。
- 抽象化のプリミティブ：関数-何らかの入力を何らかの出力にマッピングします。
- 機能構成：機能のチェーン（マッピング）。
- 集約率：1つの関数の出力が別の関数の入力に送られます。 つまり これは、コンポジション内の接続であり、関数呼び出しそのものです。
- グローバル状態：関数の引数。
OOPおよびオブジェクトパラダイムの現在の定義では、オブジェクトの構成は、せいぜい暗示されており、まったく暗示されていません。 いわゆるOOP仮説（抽象化/カプセル化/継承/ポリモーフィズム）は概念の抽象的なセットであり、後者の2つは一般的にタイピングに関連し、オブジェクトパラダイムとは関係ありません。 すべてがオブジェクトです。 オブジェクトは相互作用します。 -ここでは、オブジェクトの構成が少なくとも暗示されており、何らかの形で論理的に推測できます。
もちろん、技術的にはOOJPで何らかの形でコンポジションを見ることができますが、 オブジェクトコンポジションは OOJP の基本的かつ主要なメカニズムであり、オプションやセカンダリではありません 。
オブジェクトのパラダイムはどのように見えるべきか（機能的なパラダイムと同様）：
- 抽象化のプリミティブ：オブジェクトは、何らかの相互作用プロトコルをサポートするエージェントです。 プロトコルは、両当事者の相互作用のルールとセマンティクスを意味します。
- オブジェクト構成：互いのプロトコルをサポートするオブジェクトのグラフ。 グラフ自体は、独自のプロトコルを持つオブジェクトです。
- 集約関係：オブジェクトのプロトコルのサポート（プロトコルの理解とフォロー）。 互いのプロトコルをサポートする機能は、オブジェクトをコンポジションにバインドするだけでなく、特定のオブジェクトとの外部対話も、そのプロトコルがサポートされている場合にのみ可能です。
- グローバル状態：オブジェクトの内部状態。
オブジェクトパラダイムの際立った特徴は、オブジェクトが、関数や手順とは対照的に、純粋に変換する（つまり、状態を変化させる）プリミティブではないことです。 なぜなら グローバル状態はオブジェクト間で分散されます（OOJPではこれはカプセル化です）、オブジェクトプロトコルは状態を変更する方法になります。 これは、オブジェクトパラダイムのレベルで反映される必要があります。
このため、オブジェクトパラダイムは、オブジェクトプロトコルの変換プリミティブ、機能的および/または手続き的パラダイムを備えた任意のパラダイムを使用できます。 両方のパラダイムは、同じ抽象型なし形式で使用されます。 オブジェクトのプロトコルが機能的なパラダイムに基づいている場合、不安定なオブジェクトを取得しますが、手続き型のオブジェクトを取得してから、変更可能なオブジェクトを取得します。
早すぎるタイピング
タイピング（型システム）は、最終的に単一の目的、つまりプログラムの正確性の正式な検証に必要です。 ルールはPLの文法を介して設定され、文法に基づいた翻訳者が検証自体を実行します。
型付けが時期尚早であるということは、OOJP（クラス指向）が型の使用、クラスの型としての解釈に重点を置いていることです。 最初に目を引くのは（実際OOJAPを使用する場合、およびOOJAPを説明する場合の教科書/本の両方）、OOJAPのタイプのシステムです。 参照型と値型、サブタイプ多型、継承、リスク置換原理（LSP）、メソッドのオーバーロード、ジェネリック、抽象データ型、関数型、および関数型プログラミングの要素としてのFWP、型推論、型キャスト、抽象クラスおよびインターフェース-これらの概念はすべて、類型化の結果です。
一方で、タイピングは避けられません。なぜなら、 正しいプログラムのみを実行できます。 しかし一方で、タイピングの出現により、抽象化のセマンティクスに制限が導入されます。 アイデアは、タイピングの出現を可能な限り遅らせることです。 言い換えれば、 オブジェクト構成が定義された後にのみ、正確性の正式な検証を実行する必要があります 。 理想的には、タイピングはプラグインである必要があり、その場所はコンパイル段階の前のどこかであり、すでにコンパイル段階で検証が実際に実行されます。
タイピングをより広範に見ると、NLOでの早すぎるタイピングは、特定のタイプの実装という形でのオブジェクトパラダイムの抽象的なメカニズムの固定解釈にも現れます 。 適切なケースは、オブジェクトのプロトコルの可能なタイプの実装の1つとして、オブジェクトのプロトコル（コントラクト）が、固定構造と動作（パラメーター、戻り値）を持つメソッドの形式で厳密に実装されていることです。 C＃にasync / waitメソッド修飾子を追加する理由は、メソッド呼び出しと戻り値の間のハード（同期）接続が実際のタスクに対応しないことが明らかになったようです。 これは実際には、早すぎるタイピングの影響の修正です。 繰り返しますが、理想的には、特定のタイプのプロトコル実装はプラグイン可能で、任意のメカニズムの具体的な実装が必要です。
プラグインタイピングのアイデアは、いくつかの段階の形で私には思えます（これは、ある種のウォーターフォールソフトウェア開発プロセスではなく、すべての段階は、IDEを離れずにコードを記述するときに発生します）。
オブジェクトモデルが記述され（1つまたは複数の型指定されていないオブジェクト構成）、セマンティック抽象化のみが含まれます。 オブジェクト、そのプロトコル、オブジェクトの構成-すべては非形式的に意味の抽象化の形式で記述されます。 この段階では、オブジェクトモデルの意味は概念そのものに基づいています。
次に、帰属、つまり 意味の抽象化のための型指定されていない属性の定義（結合） 。 結果は、セマンティック抽象化に起因します。 属性は、データフィールド、プロパティなどではありません。 OOP / OOJAPから、属性は概念の意味構造を定義します。 帰属段階では、状態の概念はまったくありません。
次の段階は、 オブジェクトプロトコルの抽象（型なし）実装 （従来の方法では、メソッドの実装）です。 オブジェクトプロトコルの場合、変換プリミティブ（機能的および/または手続き的）を備えた実装パラダイムが選択されます。 属性はこの段階ですでに利用可能ですが、それらは（抽象関数や手続きのように）意味論的な抽象化のままです。 この段階での変換パラダイムの使用は、オブジェクトの抽象的な状態を意味し（変換するものがあるため）、この状態の構造はオブジェクトの属性に基づいています。
次に、 具象（型付き）実装があります。これは、型がオブジェクトとその属性、およびオブジェクトプロトコルのパラメーター/引数にバインドされる場所です。 オブジェクトプロトコルの抽象実装の抽象手順/機能は、クラスメソッドなどの従来の構造に具体化されています。
それとは別に、型のバインドは、型名を指定するのではなく、式の挿入によって行われることに注意してください。 つまり、型は式の型から推測され、明示的な初期化が保証されます。
特定の実装の段階の後、すべての概念が入力され、正式な検証を実行できます（翻訳の一部として）。
おわりに
指摘された問題は、私の意見では、NWFSが根本的に矛盾している理由です。 現在の形のNWFSとPLOが常に批判の対象になることは驚くことではありません。
3番目の問題もありますが、OCLPだけでなく他の言語にも関係します。これは、テキスト文法に基づく構文です。 現在、IDEでのテキスト文法のサポートは非常に発達しているため、疑問が生じます。なぜコードのテキスト表現が必要なのですか？ IDEは、テキスト自体が縮退するメソッドや式などの構造ブロック全体を操作します。 バージョン管理システムのバージョンをテキストとして比較しますか？ ただし、これはIDEでサポートを実装するだけの問題です。
テキスト文法ベースの構文では、メタレベルでIDEからの追加サポートが必要となるのと同じ理由でメタ機能が制限され、それらをテキストとして指定する意味はほとんどありません。 つまり メタ機能はIDEレベルでのみ実装されます。 実際、IDEは文法です。
したがって、グローバルなアイデアは、テキスト文法を使用せず、オブジェクト構成を読み取り可能なコードに変換するためのメタ機能を開発した、一貫したオブジェクトパラダイムに基づいたオブジェクト指向言語（IDE）を開発することです。