最近散歩の頻度がちょっとだけ上がっている。川は遠いと思って歩いていると意外と近いし、川岸を歩いているとめちゃくちゃ歩ける。
散歩したときの様子。ちゃんと見ると妙。
割と暗くて、人はまばらなものの割といる。
わかりづらすぎるけど素朴に光っててよかった。
肉眼だと目がうまい具合に光量を調節してくれるので、暗い中に光が滲んで綺麗に見える。
記事とか本とか、読むのに気持ちの助走がめちゃくちゃ必要になってきていて、なんでなのかと思っていたけど、読んだということにするにはそれなりに内容をちゃんと噛み砕けないと、後でこれ読んだんだどうだったみたいなのを他人から聞かれたり自分で振り返ったりするときに全く思い出せなくて、それは読んでないじゃん、となるのが嫌だなと思っているんだろうなと思った。噛み砕けたら一番いいけど、それに気を取られて助走つかずに結局全く読まないということもあるので、まず雑に読むというか見るくらいの活動をしたい。しかしちゃんと読むというのは別に意識しないとすべてを雑に見るだけになってしまいそうで、それも困る。
Chrome 90 で入っていた RegExp match indices (https://www.chromestatus.com/feature/6558676666023936) というのを見てへ〜と思ったのでちょろっとおためしした*1。
さっと見た感じでは、マッチしたものそれぞれについて、その登場範囲を配列で返してくれるというものらしい。上の 3つ目の例 ('123aaaabbbb'.match(/(aa)+(?<bee>b)/d)
)だとこういう感じになっていそう ↓
(aa)+(?<bee>b)
(全体) にマッチするのは
aaaab
で (最初を 0文字目として) 3〜7文字目[3, 8]
(aa)
にマッチするのは
aa
(後半の方) で 5〜6文字目[5, 7]
(?<bee>b)
にマッチするのは
b
(最初の1文字) で 7文字目[7, 8]
範囲の感じで終わり側の数字が 1つ多いのは、 GitHub の例を見る限り slice
とかでそのまま使えて便利になっています、というように見える。
const re1 = /a+(?<Z>z)?/d; // indices are relative to start of the input string: const s1 = "xaaaz"; const m1 = re1.exec(s1); m1.indices[0][0] === 1; m1.indices[0][1] === 5; s1.slice(...m1.indices[0]) === "aaaz";https://github.com/tc39/proposal-regexp-match-indices#examples
indices つけるの大変なので /d
フラグを明に指定しないとやりません、という仕様らしい。まさにこれがほしいぜというときにつけてあげると小粒に便利そう。 (ところで Chrome Devtools を見ていると /d
にシンタックスハイライトがまだあたってなさそう……)
As producing this array is expensive, the `.indices` property is only present when the /d flag is passed.
https://www.chromestatus.com/feature/6558676666023936
GitHub の方には、なんで /d
なのかというところに、 d
使っていいのかみたいなことも書かれていた (https://github.com/tc39/proposal-regexp-match-indices#why-use-d-for-the-regexp-flag) 。 indices という単語から取ろうとしたけど、いまある i
とかを避けつつ、他の正規表現エンジンも見て d
がすでに意味バラバラなので、まあいいかな、みたいな感じになっていそう?
あとそれに伴って他の正規表現エンジンでの様子をまとめていておもしろい (https://github.com/tc39/proposal-regexp-match-indices/blob/master/flags_comparison.md)。リンクもあるので各エンジンのドキュメントへのリンクまとめみたいになっている……。
型を公開する練習として、 pt-query-digest *1 で --output json
したときに出力される JSON の型を書いてみた。 JSON.parse()
したものにつける型を想定している。
index.d.ts とかを書いて、 package.json に types
として指定しておくと完成らしい。 npm に公開しなくても、とりあえず yarn add -D https://github.com/hogashi/types-pt-query-digest-output-json
とかやるとインストールできるのでさっと作ってみるには気楽。
値としては数値なはずだけどプロパティによって number だったり string だったりすることがあってちょっと難しい。ちゃんとコード読んでるわけでもないので、意外と null になるじゃんみたいなものもあったりしそう。あと pt-query-digest の v3.0 時点でもまだ開発中ということなので急に変わったりもしそうではある。
https://www.percona.com/doc/percona-toolkit/3.0/pt-query-digest.html#options&:~:text=json%20output%20was%20introduced%20in%202.2.1%20and%20is%20still%20in%20development
json
output was introduced in 2.2.1 and is still in development, so the data structure may change in future versions.