2017-05-29テキストエディタの「範囲」オブジェクトへの代入を「該当範囲の置換」とみなす(今日は面倒なので、である調で書く)。2.0ではRangeオブジェクトを導入しようと考えている。これはその名の通りドキュメントの範囲をあらわすオブジェクトで、テキストエディタの処理で頻繁に使われる概念ゆえに単純に導入するだけでもコードが書きやすく、読みやすくなった。今となっては後の祭りではあるが、最初から入れておけば良かったなぁとも思う。Azukiから話が逸れるが、最近Pythonの書籍を買って読んでいた。Reference“。その中で、Pythonでは配列の範囲を表すオブジェクトに値を代入することで配列の書き換えが可能という話があり、そこに興味を引かれた。[9,9,9,3,4]1行目は変数aryに0から4までの数字5つが入った配列を代入している。いう添え字の表現で取り出している。この範囲を示す添え字表現は、当然整数ではなく、Sliceオブジェクトと呼ばれるもの。これをコレクションに対して作用させるとその範囲の値を取り出してくれるのだが、これはread時の話。writeのアクセス、つまり代入も可能になっており、その場合はコレクションの該当範囲に存在する値を置換してくれる(置換される要素数と同じ数の要素を持ったコレクションを代入する必要あり)。上記の3行目が、代入を行った例である。一定範囲の書き換えをこのようにスッキリ表現できるのは、すごく魅力的だと感じる。Azukiに話を戻す。当初、Rangeオブジェクト自体は単純に「範囲」を表すデータ構造体に毛が生えた程度のモノと考えていた。PythonのSliceオブジェクトのように「それに代入したらその範囲を置換可能」にしたら面白いかもしれないなと思い始めた。テキスト全置換は次のように書けるようになるだろう(2.0完成してないのでコードは気分で...)。);}試し実装をしたところ実装は簡単だったが、できあがった後で少し改まって考えた。これ、本当に価値あるのか?代入のセマンティックスを使えなくとも、カッコ悪いかもしれないが今の考え方でも次のように書けるわけで。);}過去の経験からするとテキストエディタの処理を書いていると同時に複数の「範囲」を扱うことがある。すると、あるRangeオブジェクトへの代入で置換処理を行うと、他のRangeオブジェクトがすべて狂ってしまう。置換によって発生するオフセットを自力で反映させれば良いだけの話だが、それがアプリ側で実施必須となれば、正直混乱の元にしかならない気がする。いって、Azuki側ですべてのRangeオブジェクトを管理・更新する場合、生成した全オブジェクトへの参照(WeakReference)を大量に管理する必要に迫られてメモリ使用量・処理速度の両面でパフォーマンスが低下しかねないと思う。面白いアイデアだと思うものの、実際のところデメリットを超えるメリットが生まれるような気がしない。いや気付いてないだけかも?でも今は思い付かない。いうことで、将来の自分へ。「Rangeオブジェクトへの代入=該当範囲の置換」というセマンティックスは、いかにも魅力的だが、メリットとデメリットを吟味されたい。キャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。