ParseKitの開発者はこちら。
(私の回答で心に留めておくべきことの 1 つは、私は ParseKit の開発者ですが、フレームワークやその API を実際に設計したわけではありません。主に、Steven Metsker の著書Building Parsers With Javaにある特定の設計に基づいています。私は単に移植しただけです。それらを ObjC/Cocoa に変換します。)
ParseKit は 3 つの部分で構成されています。
- 柔軟性とパフォーマンスに優れたObjective-C トークナイザー(
PKTokenizer
、PKToken
クラス)
- 無限の先読み (クラスとサブクラス) を備えたバックトラッキング、再帰的適切なパーサーを構築するための完全に動的なObjective-C パーサー ツールキット。
PKParser
そのダイナミズムのために、このパーサー ツールキットのパフォーマンスは、大量の入力に対して貧弱です。
- 文法による Objective-C パーサーの生成- BNF スタイルの文法構文 (yacc または ANTLR に類似) を使用して、カスタム言語用の Objective-C パーサーを生成します。解析中、パーサーは Objective-C コードへのコールバックを提供します。#2のダイナミズムにより、文法を書くことは比較的簡単で、文法でできることに対する制限は比較的少ない.
上記の各コンポーネントは、前のコンポーネントに基づいています。#3 - Grammar ツールキット - は、#1 トークナイザーと #2 パーサー ツールキットの両方を使用します。
深刻な解析タスクを実行している場合は、#1 - トークナイザー - を確認することを常にPKTokenizer
お勧めします。信じられないほど柔軟で強力で、パフォーマンスは非常に優れています。入力文字列よりもトークンで作業する方が簡単な場合(通常はそうです)、おそらくこれを確認することをお勧めします。
#2 (ObjC パーサー ツールキット) については、通常はスキップして #3 に進みます。文法を使用してパーサーを作成する方が、ObjC コードを使用して作成するよりもはるかに優れているからです。
#3 (BNF 文法による ObjC パーサー ツールキット) の場合、最も重要な考慮事項はパフォーマンスです。ParseKit のパーサー ツールキットは、比較的小さな入力文字列の解析に適しています。いくつかの例は次のとおりです。
- XPath スタイルのクエリ言語
- SQL
- DSLまたはコマンド言語を比較的考慮
- 正規表現
- メニュー (または、比較的短い文のフラットな配列に分割できるもの)
ParseKit のパーサー ツールキットは、一般に、パフォーマンス上の懸念から、より大きな入力文字列の解析には適していません。いくつかの例は次のとおりです。
- XML ドキュメント
- JSON ドキュメント
ParseKit は確かにこれらのタイプの入力を解析できます (実際に解析します) が、やはり、ParseKit のダイナミズム (バックトラッキング、無限先読み) のために、専用の XML または JSON パーサーに比べてパフォーマンスが劣ります。
「ワインメニュー」の場合、私はそう言うでしょう-ParseKitはおそらく良い(おそらく素晴らしい)ソリューションです。特に、入力の個々の行を文字列の配列に分割し、それらを 1 つずつ解析できる場合。パフォーマンスは非常に優れている必要があり、学習曲線を乗り越えると、ParseKit はこれらのタイプのジョブに対して非常に強力/便利になります。
実際、メツカーのオリジナルの本である IIRC では、彼のツールキットの有効な使用例として、このようなものさえ使用されています。
お役に立てれば。