NotationTextを編集するには、要素からNotationTextを復元（オブジェクトから記法を復元）しなければならない。
シンタックスシュガーは要素に記録されないので、要素からは復元不可能。
シンタックスシュガーは復元できない？ † 
できなければ更新時展開と変わらなくなってしまう。
復元は逆変換。
- 逆変換はできそう。例えば独自のメタ文字$1を入れた正規表現で変換元/先を定義。変換元を(.*?)に置き換えるようなもの。逆変換は変換先の$1を置き換え。
- 変換元がどのシンタックスシュガーなのかを記録しておかなければならない。どこに？そうするくらいなら元のNotationTextを残したほうがいい。
シンタックスシュガーを新しい要素とすると今の設計に馴染むし、記法変換できないことに言い訳が立つ。要素が「好きなデータコンテキスト」を覚えておけばいい。→データコンテキストはビルトイン要素だけに影響。プラグイン要素はどのデータコンテキストでも同じ。記法からオブジェクトに変換したときのデータコンテキストを新しい順に参照できるように。消費しないスタック構造。
→記法を書いた利用者別にしないと無意味。でも他人が書いた記法は自分の好みの記法とは限らないので結局無意味。
新しい記法を新しい要素ということにしても、自分の好みでない記法は避けられない。同じ要素なら記法も同じにするというのが間違い。書いたとおりに残るべき。復元は逆変換ではなく、元を保存・再生すること。
シンタックスシュガーはNotationTextを残さなければ復元できない？ †
- 問題は文字列からのダウンキャスト。複数の記法が同じオブジェクトになるのも同じ問題。
- シンタックスシュガーに限らず文字列→数値ではダウンキャストになる。だから要素は記法を文字列のまま保存しておいていたはず。
- 文字列を保存しておいても入力と異なる記法系ではダウンキャストが起きてしまう。
文字列を保存するのは無意味。でも記法系に含まれるのは文字列を保存する要素ばかりなので問題は無い。 - ダウンキャストは記法系に含まれない要素だけの問題。こういう要素…プラグイン要素は記法変換と無関係なので元のNotationTextを保存しておけばいい。プロトタイピングでしているように。
ダウンキャストは解釈。解釈後なら他の記法系に変換したり、データアクセスや適切な検索ができる。
でも元の文字列は復元できない。
解釈前が欲しいとき…書いた人がまた書くとき。
解釈後が欲しいとき…書いた人以外が他の記法系で書くとき。
内部で解釈すればいいだけ…検索時。
どちらでもいいとき…上記以外。
書いた人をサポートすれば解釈後を使ってもよさそう。
これは記法系に含まれる要素（ビルトイン要素）の話。他の記法（プラグイン要素を表す記法）では記法変換が起きないので解釈前を保存しておけばいい。
シンタックスシュガー→汎用記法は逆変換可能にする。
それと自身がどのシンタックスシュガーで書かれたのかを、要素が記録。方法は？
→元のNotationTextを保存しておけばまとめて解決できる。これでシンタックスシュガーの復元は可能になる。
シンタックスシュガーは復元しなければならない？→言い回しも重要なので復元する。
数値化がダウンキャストになって復元できない問題は、ビルトイン要素にはない。ビルトイン要素ならどれも文字列を残すもの。
プラグイン要素では数値を扱うので、文字列を数値化するときのダウンキャストが起きる。元の文字列を記録しておいて復元可能に。
ビルトイン要素でもプラグイン要素でも元の情報を記録しておかなければならない。
ビルトイン要素はシンタックスシュガーを表す何か。プラグイン要素は元の文字列を記録。ビルトイン要素は要素側に任せる。記法系変換があるので元のNotationTextは役に立たない。
いずれの要素も元の文字列を記録しておけばいい。
記法変換したり、曖昧な表記を許したり、「mon」「月曜日」など元から表記法が複数ある要素はどうするか？例えばMarkdownのように。→ :ToDo/定義可能な記法と記法系変換について再考[?]
利用者によって表記法が違っていい。気分によっても表記法は変わる。情報だけでなく言い回しも保存すべき。重要なのはNotationText。
シンタックスシュガーが変換先になることはある？元の文字列を復元する以外に。あればシンタックスシュガーというより新しい記法定義と言える。記法定義すべてをシンタックスシュガーで？
シンタックスシュガーは汎用記法と対応付けるものなので、汎用記法→シンタックスシュガーがあるかどうか。→ある。
記法系変換とシンタックスシュガーと汎用記法とビルトイン要素とプラグイン要素について再考。
→ :ToDo/定義可能な記法と記法系変換について再考[?]