訪問者とリスナーに対処したので、自転車を試す時が来ました。 外部DSLを構築する方法を研究していると、練習をするという問題にぶつかりました。 DSLドリーム言語の構築方法に関するファウラーの本は、残念ながらまったく麻酔ではなく、イラクサの茂みの中の道であることが判明しました。
第12章シンボル表
すべての解析中のストレージスペース
リンク解決のための識別可能なオブジェクト。
いいですか もちろん、説明に不満はありません。
多くの言語は、コードの多くのポイントでオブジェクトを参照する必要があります。 ある場合
タスクとその依存関係の構成を定義する言語。つまり、方法が必要です。
これにより、1つのタスクが定義内の依存タスクを参照できます。
本は仕事のために収集するタスクを提示します
go_to_work -> drink_coffee dress drink_coffee -> make_coffee wash dress -> wash
そして、ここにDSLの魔法があります。それは、作成されるもの、つまりコードにコメントを付ける必要がなく、それを読んでタスク間の依存関係を判断するだけです。
しかし、私はコーヒーを飲みません、そして「マイクロソフトアプリケーションアーキテクチャ設計ガイド」という本が現れました。 優れたタスクは、Windows用のアプリケーションを開発することです。これは、これから行うことです。
MSが保証します
このガイドが役立ちます：
•アーキテクチャと設計を構築する基本原則とパターンを理解して、Microsoftプラットフォームで成功するソリューションを開発します。
•ソリューションのレイヤー、コンポーネント、サービスの設計に役立つ適切な戦略と設計パターンを選択します。
•主要な技術的ソリューションを特定して実装する。
•ソリューションの主要な品質指標と分野横断的な機能を特定して実装します。
•ソリューションを実装するための適切なテクノロジーを選択します。
•ソリューションの基本アーキテクチャの可能なバリアントを作成します。
•ソリューションの実装に役立つパターンとプラクティスグループが提供するソリューションとガイドを正しく選択します。
素晴らしい。 タスクの無料リストがあり、再編成後の形式は
1.基本原則を理解する
2. Select_strategies_and_patterns
3. Implement_key_technical_solutions
4. Implement_main_quality_インジケーター
5. Select_technologies
6. Create_possible_base_base_architecture
7. Select_suggest_solutions_and_guides
まあ、それらの間の依存関係
6-> 3 4 5
2-> 1 7
5-> 7
7-> 1
3-> 2 5
4-> 3
これまでのところ、とても良い。
このDSLの文法は非常に単純です。
grammar file... network : SEP? dependency (SEP dependency)* SEP?; dependency : lhs=ID '->' rhs+=ID+ {helper.recognizedDependency($lhs, $rhs);} ;
それだけですか？ SEPとは何ですか、IDとは何ですか？ 本当ではありませんが、私は最近文法を扱い始めましたが、一般的にはプレーンXML以外の外部DSLを扱いました。 そして、このためにここに来ました-ピット。 60ページのページングの後、私は見ました
SEP : ('-' | ' ' );
別の50
fragment LETTER : ('a'..'z' | 'A'..'Z' | '_'); fragment DIGIT : ('0'..'9'); ID : LETTER (LETTER | DIGIT)* ;
タスクはロシア語で記述されており、DSLを使用できます！
すべてをまとめて、キリル文字をサポートするためにエンコーディングを中心に踊ります
grammar WorkGrammar; network : SEP? dependency (SEP dependency)* SEP?; dependency : lhs=ID '->' rhs+=ID+; ID : LETTER (LETTER | DIGIT)* ; fragment LETTER : ( ''..'' | ''..'' | '_' ); fragment DIGIT : ('0'..'9'); SEP : ('-' | ' ' ); WS : [\t\r]+->skip;
もちろん、私は作家（開発者ではなく）ではなく、読者（ユーザー）であり、ユーザーとしてのこれは最も楽しい問題をもたらしませんでした（これらのサポートに電話せず、Googleへのリクエストでビープ音が鳴り、誰もそれらを取り上げませんでした）。
すべてが文法で見える！ F5はレクサーとパーサーを生成しました！
タスクはクラスをよく呼び出すものであり、実際にはそうではありません。
class Work { List<Work> _dep; public Work( string name ) { Name = name; _dep = new List<Work>(); } public string Name { get; private set; } public IEnumerable<Work> Dependencies { get { return _dep; } } public bool Completed { get; set; } public void AddDependency( Work dep ) { _dep.Add( dep ); } }
antlr4スタジアムでのバトル「リスナーvsビジター」で判明したように、ビジターとリスナーはかなり小さくて重く（使用することはできますが）、また自己教育のために、「自転車」でツリーを回ろうとします。
class WorksLoader { public Dictionary<string, Work> Load( WorkGrammarParser.NetworkContext context ) { Dictionary<string, Work> result = new Dictionary<string, Work>(); foreach ( var dep in context.dependency() ) { var work = GetWork( dep.lhs.Text, result ); foreach ( var right in dep._rhs ) { var depWork = GetWork( right.Text, result ); work.AddDependency( depWork ); } } return result; } Work GetWork( string name, Dictionary<string, Work> works ) { if ( !works.ContainsKey( name ) ) works[name] = new Work( name ); return works[name]; } }
コンテキストを生成するAntlr4の機能は魅力的で、クロールを大幅に簡素化します。
既に定義された依存関係を持つ文字テーブル（ジョブディクショナリ）を返すLoadメソッドを持つクラス。
最も興味深い情報源に時が来ました
____ -> ___ ___ _ ___ -> __ ____ _ -> ____ ____ -> __ ___ -> ___ _ ___ -> ___
読みにくい区切り文字（作品の名前を短くすると、かなり）わかりました、わかりました。これはA-> BCよりも何倍も優れています
リソースで言語のテキストを定義すると、作品のリストを取得できます
class Program { static void Main( string[] args ) { AntlrInputStream input = new AntlrInputStream(Resource.Input); WorkGrammarLexer lexer = new WorkGrammarLexer( input ); CommonTokenStream tokens = new CommonTokenStream( lexer ); WorkGrammarParser parser = new WorkGrammarParser( tokens ); var works = new WorksLoader().Load( parser.network()); var ready = GetReadyWorks(works); } static Dictionary<string, Work> GetReadyWorks( Dictionary<string, Work> works ) { Dictionary<string, Work> ready = new Dictionary<string, Work>(); foreach ( var currentWork in works.Select(e=>e.Value) ) { if ( currentWork.Dependencies.Count() == 0 || currentWork.Dependencies.All( e => e.Completed ) ) ready[currentWork.Name] = currentWork; } return ready; } }
F5！ うまくいく！ 場合...結果は予想されたものではありません。 問題を特定するのにかなりの時間を費やした->待ち伏せは、誰も予想していなかった場所にある->文法 一般に、それは現実的ではありません。完全ではないだけでなく、ソース資料がないため、エラーもあります。 とんでもない！
ワーキンググラマー
grammar WorkGrammar; network : SEP? dependency ('\n' dependency)*; dependency : lhs=ID '->' rhs+=ID+; ID : LETTER (LETTER | DIGIT)* ; fragment LETTER : ( ''..'' | ''..'' | '_' ); fragment DIGIT : ('0'..'9'); SEP : ('-' | ' ' ); WS : [\t\r]+->skip;
Fowlerの本によると、Antlr4でDSLを開発するとき、感情は両面で、味は苦く、説明は片側にあり、テキストは標準に達し、反対側はC＃で見つけることが不可能であり、研究はこれらのセクションの説明の一部を見つける問題によって妨げられ、開発者があちこちに注意深く散らしたバグ。
PS
提供されているものを常に使用する必要がありますか？
私の意見では、時間が許せば、独自のツリーウォーククラスを作成する方が良いと考えています。 多くはタスク自体に依存しますが。