RoslynによるC＃の拡張。 安全な通話

あなたが現在プログラミングしているX言語では何かが足りないと感じたことはありますか？ あなたの人生を絶対に幸せにしないかもしれないが、間違いなく多くの楽しい瞬間を追加するかもしれない小さな、しかし楽しいパン。 そして、黒のねたみで、あなたはこのことのあるY言語を見て、悲しいことにため息をついて、夜にあなたの最愛の枕に無力の涙をひそかに注ぎます。 起こった？



おそらくC＃は、動的に開発し、生活を簡素化する機能を追加しているため、多くの人と比べて、そのようなvy望の理由を支持者に与えません。 それでも、完璧には限界がありません。そして、私たち一人一人に-彼自身のものです。



私はこの仕事で私にとって優先事項がロズリンの歯を試してみたいという欲求であり、後で説明するアイデア自体がこのライブラリをテストするための機会とテスト例であったことにすぐに注意します。 しかし、研究と実装の過程で、一部のタンバリンでは実際に言語構文を拡張するために実際に結果を使用できることがわかりました。 これを行う方法については、最後に簡単に説明します。 それまでの間、始めましょう。

セーフコールと多分モナド

安全な呼び出しのアイデアは、null上のクラスの迷惑なチェックを取り除くことです。これは、必要であると同時に、コードを著しく詰まらせ、読みやすさを損ないます。 同時に、NullReferenceExceptionの絶え間ない脅威にさらされることは望みません。



この問題は、 Maybeモナドを使用して関数型プログラミング言語で解決さ​​れました。その本質は、ボクシング後、パイプラインコンピューティングで使用される型に値またはNothing値が含まれることがあることです。 パイプラインの前の計算で何らかの結果が得られた場合、次の計算が実行され、Nothingが返された場合、次の計算の代わりにNothingが返されます。



C＃では、このモナドの実装のすべての条件が作成されます-Nothingの代わりにnullが使用され、それらのNullable <T>バージョンは構造型に使用できます。 原則として、このアイデアはすでに空中にあり、LINQを使用してこのモナドをC＃で実装した記事がいくつかありました。 それらの1つはDmitry Nesteruk mezastelに属しています 、 別のものがあります。



しかし、このようなアプローチのすべての誘惑で、直接呼び出しの代わりにラムダ関数とLINQからのラッパーを使用する必要があるため、モナドを使用した結果のコードは非常にぼやけていることに注意する必要があります。 ただし、言語の構文手段がないと、よりエレガントに実装することはほとんど不可能です。



私の考えているように、このアイデアを実装するかなりエレガントな方法は、私の愛するJetBrains（ Null-safety ）会社の人によってまだ作成されていないJDKのKotlin言語の仕様で見つけました。 判明したように、これはすでにGroovyで、おそらくどこか別の場所にあります。



それで、この安全な呼び出しステートメントは何ですか？ 式があるとします：

string text = SomeObject.ToString();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SomeObjectがnullの場合、既に説明したように、NullReferenceExceptionを取得することは避けられません。 これを避けるために、直接呼び出し演算子 '。'に加えて定義します。 安全な呼び出し演算子「？」 次のとおりです。

 string text = SomeObject?.ToString();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして実際には式です：

 string text = SomeObject != null ? SomeObject.ToString() : null;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

安全に呼び出されたメソッドまたはプロパティが構造型を返す場合、割り当てられた変数はNullable型である必要があります。

 int? count = SomeList?.Count;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常の呼び出しと同様に、これらの安全な呼び出しはチェーンで使用できます。次に例を示します。

 int? length = SomeObject?.ToString()?.Length;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

式に変換します：

 int? length = SomeObject != null ? SomeObject.ToString() != null ? SomeObject.ToString().Length : null : null;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、追加の関数呼び出しが生成されるため、私が提案している変換の欠点のいくつかが隠されています。 実際、たとえば次の形式に変換することが望ましいでしょう。

 var temp = SomeObject; string text = null; if (temp != null) text = temp.ToString();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、Roslynのやや冗長な性質により、例が肥大化し、退屈にならないように、変換をより単純にすることにしました。 ただし、これは次の部分にあります。

プロジェクトロズリン

ご存知かもしれませんが、 Roslynプロジェクトの CTPバージョンが最近リリースされました。C＃およびVB開発者は、マネージコードを使用して言語コンパイラを完全に書き換え、これらのコンパイラへのアクセスはAPIとして公開されました。 これにより、開発者は多くの便利なことができます。たとえば、非常に便利で簡単な分析、最適化、コードの生成、スタジオ、および場合によっては独自のDSLの拡張機能とコード修正の記述が可能です。 確かに、すぐにリリースされることはなく、Visual Studioの1つのバージョンを介して既にリリースされますが、今それを感じたいです。



問題の解決に移りましょう。まず、この言語の拡張機能が実際にどのように使用されているかを想像してみてください。 明らかに：いつものように、お気に入りのIDEでコードを記述し、必要に応じて安全な呼び出し演算子を使用し、コンパイル中にProjectを押します。ProjectRoslynを使用して作成したプログラムは、これらすべてを構文的に正しいC＃コードに変換し、すべてがコンパイルされました。 失望させていただきますが、Roslynでは、現在のcsc.exeコンパイラの動作を妨害することはできません。 同じvNextスタジオで、コンパイラがそのマネージカウンターパートに置き換えられると、そのような機会が現れる可能性があります。 しかし、彼女がいなくなっている間。



同時に、すでに2つの回避策があります。

1. 同じRoslyn APIを使用して、現在のcsc.exeの代わりに独自のコンパイラを作成し、csc.exeを独自のアナログに置き換えてビルドシステムを変更することができます。コード。
2. コンソールプログラムをソースコードファイルを変換し、受け取った新しいソースをObjフォルダーに保存するビルド前タスクとして使用できます。 ビルド前フェーズのxamlファイルが.g.csファイルに変換されるとき、WPFは現在非常によく似た方法でコンパイルされています。

Project Roslynはいくつかのタイプの機能を提供しますが、重要な機能の1つは、抽象構文ツリーの構築、分析、および変換です。 さらに使用するのは、この機能です。

実装

もちろん、以下に書かれているものはすべて単なる例であり、多くの欠陥に悩まされており、大幅な改善がなければ実際に使用することはできませんが、そのようなことが原則的に行われることを示しています。

実装に移りましょう。 プログラムを作成するには、最初にRoslyn SDKをインストールする必要があります。これは、 リンクからダウンロードでき、Visual Studio 2010用のService Pack 1とVisual Studio 2010 SDK SP1も最初にインストールする必要があります。

これらすべての操作の後、Roslynサブ項目が新しいプロジェクトを作成するためのメニューに表示されます。これには、いくつかのプロジェクトテンプレートが含まれています（その一部はIDEに統合できます）。 簡単なコンソールアプリケーションを作成します。

たとえば、次の「ソースコード」を使用します。

 public class Example { public const string CODE = @"using System; using System.Linq; using System.Windows; namespace HelloWorld { public class TestClass { public string TestField; public string TestProperty { get; set; } public string TestMethod() { return null; } public string TestMethod2(int k, string p) { return null; } public TestClass ChainTest; } public class OtherClass { public void Test() { TestClass test; string testStr1; testStr1 = test?.TestField; string testStr3 = test?.TestProperty; string testStr4 = test?.TestMethod(); string testStr5 = test?.TestMethod2(100, testStr3); var test3 = test?.ChainTest?.TestField; } } }"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このソースコードは、安全な呼び出しステートメントを除き、構文的に正しいだけでなく、コンパイルされますが、これは変換には必要ありません。



まず、ソースファイルから抽象構文ツリーを構築する必要があります。 これは2つの方法で行われます。

 SyntaxTree tree = SyntaxTree.ParseCompilationUnit(Example.CODE); SyntaxNode root = tree.Root;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構文ツリーはSyntaxTreeクラスによって定義され、奇妙なことに、ベースSyntaxNodeタイプから継承するノードのツリーであり、各ノードは特定の式（バイナリ式、条件式、メソッド呼び出し式、プロパティ定義、変数）を表します。 当然、SyntaxNodeの下位クラスのインスタンスによって、絶対にC＃構造を表示できます。 さらに、SyntaxTreeクラスには、キーワード、リテラル、識別子、句読点（中括弧、括弧、コンマ、セミコロン）の最小構文ブロックのレベルで解析するソースコードを定義するSyntaxTokenセットが含まれています。 最後に、SyntaxTree inにはSyntaxTrivia要素（コードを理解する上で重要ではない要素）が含まれます。スペースとタブ、コメント、プリプロセッサディレクティブなどです。



ここで、1つの小さな詳細を知っておく必要があります-Roslynはファイルの解析に非常に寛容です。 つまり、良い方法ではありますが、分析のために構文的に正しいソースコードを提供する必要があります。実際、何らかの方法で何らかのテキストを絶対に何らかのASTに変換しようとします。 構文的に正しくないコードを含めます。 この事実を使用します。 構文木を構築して、Roslynが安全な呼び出し演算子を木に表示する方法を調べてみましょう。



Roslynの観点から見ると、テストはすべてテストでしたか？.TestFieldは、条件-「test」、式「when true」-「.TestField」、および空の式「when wrong」を持つ三項演算子です。 この情報を武器に、ツリーを変換します。 ここで、Roslynの別の機能に遭遇します-構築する構文ツリーは不変です。つまり、既存の構造を直接修正することはできません。 しかし、それは問題ではありません。 Roslynは、そのような操作にSyntaxRewriterクラスを使用することをお勧めします。これは、SyntaxVisitorクラスを継承します。SyntaxVisitorクラスは、名のとおり、悪名高いVisitorパターンを実装します。 特定の各タイプのノードへの訪問を処理する多くの仮想メソッドが含まれています（VisitFieldDeclaration、VisitEnumMemberDeclarationなど、合計で約180個あります）。



子孫のSyntaxRewriterクラスを作成し、VisitorConditionalExpressionメソッドをオーバーライドする必要があります。このメソッドは、訪問者が三項演算子である式をバイパスするときに呼び出されます。 次に、特に小さいため、実装コード全体を提供し、いくつかの説明のみを追加します。

 //              public class SafeCallRewriter : SyntaxRewriter { //          ?. public bool IsSafeCallRewrited { get; set; } protected override SyntaxNode VisitConditionalExpression(ConditionalExpressionSyntax node) { if (IsSafeCallExpression(node)) { // expression  ,   null string identTxt = node.Condition.GetText(); ExpressionSyntax ident = Syntax.ParseExpression(identTxt); // expression  ,      != null string exprTxt = node.WhenTrue.GetText(); exprTxt = exprTxt.Substring(1, exprTxt.Length - 1);//     exprTxt = identTxt + '.' + exprTxt; ExpressionSyntax expr = Syntax.ParseExpression(exprTxt); ExpressionSyntax synt = Syntax.ConditionalExpression(//  condition: Syntax.BinaryExpression(//  ident != null SyntaxKind.NotEqualsExpression, left: ident, //  -   right: Syntax.LiteralExpression(SyntaxKind.NullLiteralExpression)), // null whenTrue: expr, whenFalse: Syntax.LiteralExpression(SyntaxKind.NullLiteralExpression)); IsSafeCallRewrited = true; return synt; } return base.VisitConditionalExpression(node); } //          private bool IsSafeCallExpression(ConditionalExpressionSyntax node) { return node.WhenTrue.GetText()[0] == '.'; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の最初の実装はASTの論理構造でのみ動作しようとし、式のテキスト表現では動作を軽視しようとしましたが、その複雑さはすぐに考えられるすべての制限を超え始めました。 安全な呼び出しとそのタイプを定義するための関数は、フィールドとプロパティ、メソッドの呼び出し、安全な呼び出しのチェーンの3つだけでした。これらはすべて、SyntaxNodeクラスの異なる継承者であると思われたためです。 完全に吐き出した後、私は最初のオプションをゴミ箱に捨て、2回目はRoslynが提供する便利なGetTextおよびParseExpression関数と、行レベルでのいくつかの汚いハックを使用しました:)。



また、構文ノード（この場合はConditionalExpression）の作成プロセスと、この場合の名前付きパラメーターのようなC＃チップの使用の快適性にも注意することをお勧めします。 そうでない場合、構文ノードを構築するプロセスで、夢中になる可能性があります。



メインプロシージャのコードは次のとおりです。

 static void Main(string[] args) { //   SyntaxTree tree = SyntaxTree.ParseCompilationUnit(Example.CODE); SyntaxNode root = tree.Root; SafeCallRewriter rewriter = new SafeCallRewriter(); do { rewriter.IsSafeCallRewrited = false; // ,           root = rewriter.Visit(root); } while (rewriter.IsSafeCallRewrited);//        1 maybe- root = root.Format();// Ctrl+K, Ctrl+D Console.WriteLine(root.ToString()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コールチェーンを処理するには、ツリーのいくつかの書き換えが必要であることを説明します。 もちろん、これは再帰によって行うこともできますが、おそらくこの場合、コードがぼやけるだけです。 また、Formatの素晴らしい機能にも注意してください。 指定されたスタイルのコードの書式設定をプログラムで行います。 必要なすべてのSyntaxTriviaをASTに追加します。



結果として、次のコードがあります。

 using System; using System.Linq; using System.Windows; namespace HelloWorld { public class TestClass { public string TestField; public string TestProperty { get; set; } public string TestMethod() { return null; } public string TestMethod2(int k, string p) { return null; } public TestClass ChainTest; } public class OtherClass { public void Test() { TestClass test; string testStr1; testStr1 = test != null ? test.TestField : null; string testStr3 = test != null ? test.TestProperty : null; string testStr4 = test != null ? test.TestMethod() : null; string testStr5 = test != null ? test.TestMethod2(100, testStr3) : null; var test3 = test != null ? test.ChainTest != null ? test.ChainTest.TestField : null : null; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、Roslynとの最初の知り合いは成功し、言語拡張機能を作成することは必ずしも必要ではありませんが、一般的にその見通しは非常に良好です。 おそらく、愛好家がいる場合、これはより深く、より真剣に行うことができます。 C＃には、まだ足りないものがたくさんあります。 :)



PS Roslynのこのような使用のもう1つの例は、私を大いに助けてくれました。