mifumi323/SearchQueryStructure: 検索構文とかに使われるAND/OR/括弧などの構文解析をするやつ
新しいライブラリとして作り始めました。
「検索クエリ」ってよく言ってるよなってことで、Phrase→Queryに、解析(parse)の逆に構築(build)もできていいかもなって思って、両方に共通する構造化データから、Parser→Structureに名前を変更しました。
実装はまだ始めていませんが、最初の段階はSearchPhraseParserからコピーしてきて結果だけ何かしらのクラスを作って当てはめればいいかなって思ってます。
オプションで柔軟にとか、ビルドできるようにとかは最初の一区切りまでできてから。
新バージョンか別バージョンか、どうするか決めかねているんですが、データの返し方を大幅に変えようかと思っています。
現状だと、全部連想配列で返しているんですが、今どきのPHPだと、型をしっかりつけたほうがいいんですよね。
まあ、それを想定しての現状の関数名ParseToArrayで、単純にParseToObject関数を生やすのも一つの手なんですが、もう一つやりたいことがあって、そっちが問題なんですよね。
現在、パーサーはParserクラスで、実際にパースするParseToArray関数は、static関数です。
パーサーオブジェクトを作らずに呼び出す形なので、パーサーオブジェクトにオプションを持たせてデフォルト以外の動作をさせるとか、クラスを継承して使用を拡張するみたいなことが一切できません。
だから、オブジェクトを作る前提の別クラスを新たに用意する、というのも考えたのですが、クラス名はParserが完璧すぎて別の名前使いたくないし…。
で、そこまでやると、使い方が根本的に変わってしまうので、そもそも同じライブラリである必要があるのか？って疑問もわいてくるのです。
しかし、別ライブラリとして作るなら、いったいどんな新しい名前にするの？って話にもなるわけで。
サーチに使うと限らないのでサーチの部分変えるか？
検索語の組み合わせを取り扱うのでフレーズという単語を使ったけど、もっとぴったりな単語はあるか？
パーサーの部分は今のところ完璧なので名前から外す気はない。
レンタルDVD情報。
Release 2.0.0 · mifumi323/TgwsMark
結局、リリースタグ付けてなかったのが原因でした。
よそ様のライブラリと比較して、よそ様のライブラリのほうにはcomposer.jsonにversion記載がないのにバージョン指定でインストールできていて、そこで気付きました。
私の他のライブラリも同じようにリリースタグを忘れていて、バージョンアップしたのにバージョンアップできない状態になっていたので、そちらにもリリースタグつけておきました(Mifuminator、SearchPhraseParser、TwitterLib)。
4階のカンフー-1。
足技中心の近接攻撃の衣装です。
だからまあ、剣士に近い使い勝手だけど、結構コンボが繋がる感じ。
リーチ短めでダメージ受けやすいのと、足場が悪い中での戦いもあったりして、何度かミスになってしまいました。
一度取り逃しも発生して、2週目でキラメキストーンコンプしました。
カウガールのアクションリハーサル。
人入りの樽と爆弾入りの樽が出てきて、人入りの樽だけ投げるやつ。
これまでのアクションリハーサルと比べて、見てから対処しても充分間に合うので、死に覚えゲーみたいな部分は少なく、1回のチャレンジで最高報酬条件の45人を超えることができました。
他の写真は以下から。
プリンセスピーチ Showtime!(2024/06/02)の写真
正式な曲目が公開されたので反映しました。
『森は枯れても2024』が新録ですね。
映画も森を舞台とした話なので、実際に使われる可能性が高そうです。
名前空間とか調整して、再公開しました。
これでもうばっちりだと思ったのですが、試しに自分のプロジェクトに入れようとしたら、うまくいきませんでした。
他の人のライブラリとかと見比べても決定的に足りないものはなさそうに見えるけど…。
急ぐ用事ではないし、ちょっと後日考えてみよう。
他のライブラリも名前空間変更したのですが、どうにも微妙な感じです。
一応、メジャーバージョンを上げておいたので、バージョン指定で導入している人には悪影響ないとは思うのですが。
0.1.0-alpha7リリースしました。
naver系の追加です。
2.0.1リリースしました。
名前は似ているけど別物です。
特定パターンのエラーを解消して、テストも追加しました。
でもCIのテストは通っていないんですよね…。
手元ではテスト通ったんですが。
かっこの片割れだけしかない文字列を渡すとエラーになるバグがあったので直しました。
それはそうと、Packagistに登録はしているけど、ちゃんとした登録にはなっていないようですね。
一応、自分で使う分には困らないし、私以外もどうやら使っていないようですが、せっかくだからちゃんとした登録をしておきたいですね。
とりあえずPackagistで公開。
テストとREADMEをまだまともに作ってないのでTGWS側にはその辺整備してから公開する予定。
Composerで取り扱えるように準備中…。
ライセンスもちゃんと定めて、まともにオープンソース化します。
SearchPhraseParserの実用的なサンプルを作りました。
思えば、仕様を確認するためのサンプルしか用意していなくて、ちゃんと使えるサンプルは実質ないままでした。
SearchPhraseParserのバージョン1.1.0を公開しました。
今回は大文字小文字の区別をするオプションをつけました。
Googleなどでは「OR」などの演算子は大文字でないと反応しないので、それに合わせるためのオプションです。
アンパンマンDB3のデータベース管理クラスを検索機能のクラスと編集機能のクラスに分割しました。
現状のアンパンマンDB2のように何でもかんでも1箇所に集約しすぎてソースがごちゃごちゃしてきたのと、ユーザー側のページでも呼び出していないだけで編集機能そのものは動く状態で存在していたのが理由としてあります。
編集機能は結構大きいので、ユーザー側のページでは絶対使わない編集機能を読み込むのも無駄な話だし、もし万が一間違えて編集機能を呼び出すコードなんて書いてしまったら大変です。実際紛らわしい内容のメソッドもありますし。
あと、SearchPhraseParserを微妙に更新しました。
本体の動作が変わらないほど本当に微妙な変更ですが。
ただ、オプション項目を追加する程度のことはできたかなーって気がします。
検索文解析器、公開しました。
やってくれるのはツリーを作るところまでなのでその先の処理は自分で作らなければいけません。
検索文解析器微調整。
あまり使われなさそうな構文を削りました。
検索文解析器、構文解析の都合上やたらと深くなりがちなツリー構造を単純化するようにしました。
これをやっておかないと最終的にSQL文を作るときに括弧だらけになってしまって見通しが悪くなるのです。
結局LL法の構文解析をまともに実装するやり方が理解できなかったので、拡張性だとか可読性だとか全く無視で、構文規則を直接関数に書き下して無理やり実装してしまいました。
とりあえずこれで検索ワードの構文ツリーが作れるようになったので、もうちょっと調整すればいろんなところに組み込めそうです。
日本がなんか世界一になったそうですね。
めでたいことです。
LL法なかなかわからんです。
集合論とかももうちょっと勉強せねばならなさそうです。
いつか頓挫したあのスクリプトよりは簡単だとは思うのですが…。
検索条件解析プログラム、字句解析解析中に追加の処理を入れられるようにしました。
これにより特殊な書式で書かれたものも解析できるようになりました。
そういえばライモンシティの連中、レベル20以上差があってもタイプ相性とその他条件次第ではなんとか勝てることもあるようです。
たとえばレベル38ガーメイル(虫・飛行)でレベル65ドレディア(草)を倒せたりとか。
もっとも、攻撃を4分の1に軽減してやっと1～2発耐える程度なので安定はしませんが。
複雑な検索条件を構文解析するPHPプログラムを作成中です。
アンパンマンDBバージョン3用ですが、構文木まで作れればアンパンマンDBに限らずいろいろ応用が利きそうです。
PHPにはyaccとかlexみたいなのが見当たらないけど、少なくとも字句解析は正規表現でなんとかできそうです。
構文解析については、これも正規表現で頑張るか、昔頓挫した言語作成の延長線上でやるか、どちらかで頑張ることになりそうです。