OSS
勉強会・LT
PHPerKaigi
レギュラートークとLT。 事前収録してDiscordで追加・補足情報投げ込むのも、ライブでLTするのもどっちも楽しかった
5分弱でマージされてビビった・・・w
お声がけ頂いて、記念すべき第1回目のゲストとして参加しました。
(リハーサルも本番も、ただ自分も興味あることを楽しくお喋りさせていただいただけ・・
『エラスティックリーダーシップ ―自己組織化チームの育て方』のレビュー Roy Osherove (にちようびさん) - ブクログ
ということなので、他の本と並列しながら隙間隙間で読んでいったり〜で、11月に読み始めて年末に読み終えた。
(自分の場合、ブクログは「読み始めたタイミングで本棚に登録」「読み終えたら読了日を記録」という使い方をしている。)
コレはとっても良い本で、2020年は良い本との出会いがたくさんあったなぁと感じるが、個人的に年間ベスト5に入るかも知れない。
ふと「読書記録を晒していなかったんだな〜」と気付き、折角なので読みながら手元で付けていた読書メモを転記してみる。
全篇を通読してはいるが、「10章: 管理職のためのマニフェスト」は今の自分が読んでも中々遠く想像がつきにくいような印象があったので、特にメモはとっておらず。
また、本書の「後半」にあたる第Ⅴ部・第Ⅵ部については、オムニバス的なエッセイ集という趣があり、今回は「前半」ほど熱心にメモを取らなかった。内容については、ところどころ刺激的だったりハッとさせられるようなものが含まれている。また折に触れてこっちも読み返したいし、その際にはなにかのメモを作ったりもするかも知れない。
ということで、以下は雑多に作った読書メモからの転記。
続きを読む皆さんは「=== null」と「is_null」ってどう使い分けてますか?(というか使い分ける?」
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年12月13日
私はis_nullが好きなのですけども。nullは特殊な感じがして・・
と軽い気持ちでツイートしてみたら知見が寄せられて面白かった話。
「全然その辺りは好みの問題じゃないかな〜?」というのがあったんですが、1発目・2発目からガッチリ論拠のある意見をもらって「おぉ、なるほど・・・」となった次第。
PHP 8 で作る JSON パーサ / php8-json-parser - Speaker Deckを見ていて、「お! ===
だ!」と思って気になったんですよね〜。
該当コードは↓。
github.com
(ちなみに発表内容がすごく面白かったです、今だとLIVE配信のアーカイブ観れますが恐らく後日セッションごとに切り分けられたものが?上がると思うので、動画のリンクは止しておきます)
自分的に「is_null
の方が読みやすくない?」って思っているフシがあったので、さてどっちだろうな〜と。
※ 他の方のツイートを埋め込み表示にするの何となく気がひけるので、リンクの明示だけにしておきます
is_null()
を使う事が多いな〜と思っていて、
null
と「同じ」である、という表現が何となく気持ち悪いような
=== null
の方が「しっかり」してそうだな、って話を聞いてて思ったってことで、以下寄せられた意見
=== null
派「FQSENで記述しないとオーバーヘッドが大きくなる」というもの。
このレスが速攻で飛んできて「すげぇ!」「ありがてぇ!」ってなってしまったw
(いや本当に、反応もらえたとしてもゆるふわっとした感じだと思ってたので。)
PHP的に is_null($v);
は2通りの解釈ができて、
ns\is_null()
というもの\is_null()
というものもし \is_null()
と明示的に呼ばれていれば問題は起こらないが、そうでない場合、まず1のis_nullを探してから2のis_nullを呼ぶ、というものになる。
もちろん use function is_null;
と書けば問題はない、が、面倒くさいのでは・・・?と(個人的に)思った。
それだったら最初から === null
でいいじゃん、というもの。
コレ自体は「言われてみればそうだな、確かに確かに」と思ったんだけど、補足のリプで「opcodeを追ってみればこんなに自明」という風に情報を示されて、「なにそれ面白い早く俺もそっちに行きたい」という感情を刺激されてしまった・・・・
また、別観点として「そもそも明示的に \hoge()
と書くの良いかもな〜」というのも思った。
誤読が少ないし、分かりやすい。
確かに「is_nullを使うためにuse〜を一行書きたい?」っていうと(個人的には)大袈裟な気がするので、恐らく「僅かなオーバーヘッドを許す」が落とし所になるかなぁとは思いつつ、
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年12月13日
別の話として「(is_nullに限らず)明示的に\を付けるとそれはそれで分かりやすいかも?」て気持ちがたまに湧きます😟
ちなみに、逆に言うとルート空間の明示を省略して書くことで「関数をぶっ壊す」というのも可能で、実際にfile uploader周りのテストを書く時に「is_uploaded_file()
を無理やりtrueにする」みたいな処理を過去に使ったことがある。
<?php namespace Vendor\Package\FileUploader\Uploade { fnuction is_uploaded_file($filename) { return true; } }
みたいな。
if (is_null($v))
とした時に、
とか何なん!的なもの。(って書き方だとニュアンス伝わりにくい、「関数をコールするよりは式のほうがシンプルじゃないか」的な)
また、「他の値(例えば is_true()
)の時もそうやってやるんか??」と言われ、なるほど〜見方によっちゃ揃ってないな?という。
これもまたなるほど・・・
is_int
とか is_string
とかは使い道ありそうだけど、「nullかどうか」は「null以外はnullじゃないの」となるので、違和感があるな〜とも思った。
「値が1つしか存在しない」というのを前提にすると「nullを特別扱いするか?」が恐らく感覚の境目になってきて、
という対立する判断に進みそうかもな。報われない気持ちを整理したくなるな。
そういや全く関係ないけど、is_string()
に Stringable
が来たらどうなるんだろうな?勿論「objectなんだからstringじゃない」と言ってもらわないと困る気がするけども。
(お、こういう時にphptを見れば早いのでは・・?💡)
==
じゃね?GolangやTSを例に引いて、「”無”なオブジェクトとの比較も ==
で行うしね、違和感とか覚えなくて良いはず。寧ろ自然じゃないかね?」というもの。
言語特性としてPHPは「色々な歴史がごちゃまぜになっている」という面があると思うので(良い悪いではなく!ただ、間違いなく特徴ではある)、使い手側が「負債を引きずり込みすぎない」というのは意識した方が良いよね〜って気持ちも個人的にあります。
(しかしそういう「PHPのゆるさ」みたいなところについて、RFCでこの仕様はこの言語の暗黒時代の遺産を引き継いでいるって表現を見た時は笑ったw)
その観点から言うと、「他の言語やコミュニティの例に倣う」というのは時に効果的だな〜って思います。
is_null()
派SELECT * FROM table WHERE a = NULL;
って書きませんもんね・・! 全く違う世界の話を引きずらないで、と言われればそうなのですが、やっぱり「nullは中身が確定していない事を表す」はずなのに「イコールで比較とは果たして・・?」っていう気持ち悪さが頭をよぎります。
という人が他にも居てよかったw
(なおココでpy の if v is None:
を挙げている人がいないのは、私のTLの偏りだと思います😃)*1
ちなみに、@d_horiyama_webさんにもらった「lintに従う」というのは凄く良い判断基準だよな〜と思っていて、まさにこういう「自転車置き場の色」は機械に覚えさせておいて判定させる、というのが良いですよね。*2
静的解析等で「=== null
を使え」という風になっていれば、それは凄く正しいというか「そうしましょう、なぜならそうすることが良いからです」みたいな話に落とし込めるので現実的に素敵な話。
ただ、これは独自に拡張していたルールなのかな・・?パッと探ってみて見つけられなかったです💦
Pslamでの挙動が一時的に不吉だった時期があったのかな?
=> is_null($value) not treated same as null === $value · Issue #2578 · vimeo/psalm · GitHub
実際問題、そういうのルール作って良い気がする。
Psalm - a static analysis tool for PHP
て感じで、Psalm、PHPStan、Phanだと検出されたIssueなし。PhpStormでもソレらしきInspection見つからなかった・・かな?
「nullを示すもの」を判別するための「専用の書き方」があるのであれば、それを利用することで読み手の注意を引いたり「何をしたいのか」を判読するコストが下がるのでは?というもの。
(割と期間を一緒に働いていた元同僚なので、そういう温度感を互いに共有していたのかもな〜というメタな感想もいだきましたw)
それと、このツイートで情報として「PHPCSがsquizのrulesetで is_null()
を禁止している」という情報が 💡
確かに、見てみるとForbiddenFunctions
として設定されています。
なるほど、PHPCSの文脈で探ると何かあるかな・・?と思ったら、PHP-CS-FixerのIssueで興味深いものが出てきますね。
ここでベンチマークもはられていて、何だか条件によっては\is_null()
の方が有利になる?という話も。
- PHP 5.6: is_null($x) is 2.5x slower than null === $x with opcache disabled, and 2.2x slower with opcache enabled
- PHP 7.0-7.2: the performance of both is the same, with and without opcache
- PHP 7.3-7.4: is_null($x) is 1.2x faster than null === $x with opcache disabled, with opcache enabled there's no noticeable difference (but still, is_null() is 0.2% faster).
とはいえ、このIssue自体は「はっきりしたことが分かるまでは積極的にやる程でもないかなぁ」「生じたとしても微細な差分なので、今までのやり方を変えるほどかどうかは微妙?」というような温度感になっています。
(closeはされていないけども)
どっちかっていうと === null
の方が分かりやすいのかもな〜って気がしてきました!
が、
というものです。
ちなみにアンケートも実施されているのですが、===
が優勢かな 😗
あと、他に「is_null()
が (isset()
と違い)関数なのこんがらがるね」という声もありました。
「is_hogehogeとishogehogeがあるの命名ばらばらで気持ち悪い」と思うか、仮に is_set()
だったとしたら「is_hogehogeという命名の中で関数だったりそうじゃなかったりするの怖い」と思うか・・・?
って考えると、脳みそが痛くなりそうですね!とか思ってフフッてなりました。
なんにせよTwitterで色々と意見もらえたのが楽しい、こういうのあんまり仕事とか同チーム内でやると変な疲れ方しそうでもあるので・・!
*1:これ https://twitter.com/tadsan/status/1338075560979779584 は私も思うところ、というかinstanceof だけ文章っぽいのが違和感あるんだよなぁ。。
*2:今回の場合、技術的な観点での「こっちの方が良い」という意見が寄せられてますが、「readabilityに勝るもの無し」な差だと思うので「些細な問題」と言わせてもらっています。もちろん、意見表明(まして根拠の説明)をしてくれた人を軽んじるとかそういうアレじゃないです!!!
いや、タイトル「何が何だか」って感じですが・・・
明日、どころか・・もう日付変わって本日行われるPHP Conference Japan 2020にてお喋りしてきます 🎉
自分は「Composer2.0」の話をしますよ〜とプロポーザルを提出し、採択して頂きました。
実は「Composerの新バージョン」については、昨年のphpconでも取り扱おうとしていた話題ではありました。単純に発表時間が足りなかったのと、また開発状況としてもまだまだ途上だったので見送っています。
それが、1年越しに開催される同イベントで、CfPオープン期間には「v2リリースの目処が立ち」本番を迎えるまでに「安定版がリリースされ」・・・と、着実に続く時代の流れを感じながらも「もしかしたらずいぶん遠くに来ちまった」とも思ったりしちゃっています。
さて、そんな訳で今回お話する内容は自分の中では「前回の内容に引き続き」という面もあります。
(ただ、結局のところ実際にスライドに落としてみたら独立した内容になりましたがw)
その内容を知らなくても理解できる・・というか「読んでいたところで直接の役には立たん」かも知れませんが、
このセッションタイトルやプロポーザルに反応してくれた方であれば「Composerの話」は面白がってくれるんじゃないかな?ということで、紹介しておきます。