なんたらノート第三期ベータスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。読者です読者をやめる読者になる読者になるなんたらノート第三期ベータ2009-09-03エルビスよ、aかbかcかdから肯定値を取り出せPHPJavaScriptPythonGroovyJava新しいPHPとかGroovyとか次のJavaとか、三項演算子の省略でElvis演算子(?:)なるものがあるそうで、どのぐらいおいしいのかを考えました。b)はやっぱり評価されるべきものだよね、ってことを意味してるんじゃないのかな?三項演算子の是非について、ちょっと前提を。http://blogs.wankuma.com/rti/archive/2008/06/25/145486.aspxhttp://blogs.wankuma.com/ma2/archive/2008/06/26/145583.aspxhttp://d.hatena.ne.jp/NyaRuRu/20080626/p1例えば、先日聞いた話ではコーディング規約に三項演算子すら禁止している会社があるらしい。理由は、多くの社員が、そんなものを使わないから。バカのくせに社員のスキルアップを妨害するんじゃねーよ。...と、同調してネットで笑い飛ばすのは簡単だけど、本当にそうなのかを考えたい。課題aかbかcかdの順に、とにかく肯定的な値(言語によるが、少なくとも非NULL値)のものをどれか取り出す関数someofを作れ。エルビスでやってみる。言語はGroovyで。いうか、これならむしろ、関数を定義するだけ無駄で、関数の中身そのまま展開して書いたほうがわかりやすいかも。これに対して、三項演算子がない言語だと仮定して、if文でやってみる。言語はJavascript。コード圧縮ツールの効率悪そうだなぁ。単一式じゃないから、呼び出し元にインライン展開できないじゃん。ifが式なOCamlとかなら話は別だけど、多くの言語で、ifは文だよね。d;}コード圧縮効率としては理想的。C++だったら間違いなくinlineつける。いうか、型あいまいなままのほうがいいから、#defineかな。古いCからでも使えるし。ここで、演算子の結合規則上これでいいことが理解できないとだめで、自信がない人はやたら括弧をつけたがり、結果、こんどは括弧の対応に悩まされることになる。これ、PHPにもっていくと意図に反した動きになる。PHPの三項演算子は、他の中括弧族とは異なる結合優先度だから。http://d.hatena.ne.jp/pasela/20080524/ternary(たぶんパーサのバグで、でも、このバグを取ると、こんどは既存のコードが動かなくなるから、できないんだろうな)実際の有用性はどうあれ、たしかに、(本物の)プログラマー以外に、この「徹底して"式"であり続けてくれる非線形な演算」の価値は、認知されていなさそうです。あんなに多くの(平均的)プログラマーを抱えるPHPコミュニティですら、この有様なんだもん。どんなクズがいるかわからないこの業界全体において、正しく評価されることはないでしょうね。本当にクズなところは、容易に「ビジネスロジックで正規表現禁止」「あんな暗号みたいなものは嫌だ、フローチャートで表せないじゃないか」とか平気で言うんだろうな。(あ...ってことは、PHPの開発チームは本物のプログラマーじゃないという意味になるか、彼らはプログラマーだけど、PHPを言語とみなして開発していないという意味になるか、二択だね)目の前の学習コストの支払いを避け、結果、無自覚に損していても(式になれるのに文で甘んじていても)、その事実にすらおそらく気づけない。式であるありがたみは、三項演算子を使うのが自覚への近道だから。逐次コマンド実行という発想から、式と文と関数という発想(PascalからCへの発展)へのシフトが起こらない。組織的に理解されないから、さらにその中にいる個人の認知が遅れる。出たら、この泥沼を思い出そうっと。応用さらに進んで、可変長引数に発展させることを考えます。引数が4つ固定じゃ使い道が限られるから。1];}ややこしくなってきたので、Pythonでやります。args[-1]面白い実装としては、こんなのも。書くと、こんなことに。NonePythonだとランタイムの都合で非効率的だけど、末尾再帰最適化が期待できる言語エンジンで動く場合を考えると、むしろこれが大正解。結論と、これだけやってみて、someof関数は意外と高度な話になってくることがわかった。仕事用にAPIを設計しているのなら、どの段階でやめておくかで、見積もりが大きく変わる要因だ。ところで、そもそもこんなsomeof関数を作る必要がないぐらい、もとの言語機能が充実してたら、誰も、どれぐらい高度なsomeof関数を書くか、あるいは三項演算子を使うか、なんて、変なところで迷うことがなくなり、見積もり精度が上がることでしょう。関数型言語の学者先生にはピンと来ないかもしれないけど、これは、言語理論じゃなくて生産性の問題。生産性の安定は工学のテーマ。次のJavaがエルビスを選んだ動機に納得いく。&quot;nothing&quot;).toString();でいいじゃん。逆に、言語機能にあるものを使えばいいから、むしろ、someofみたいな関数自作は禁止、ってこと。&quot;nothing&quot;)でOKでした。OR演算の結果が、論理値に化けず、元の値を保持するので。テンプレートエンジンだと、ZopeとかPHPTALとかのTAL系の式がそれ。どれかあれ?そう考えると、PHPはかつてあんなに三項演算子をいい加減に扱っておきながら、こんどは急にエルビス演算子を導入、なんてことやって、言語基盤は大丈夫なんだろうか?http://d.hatena.ne.jp/pasela/20080524/ternaryhttp://d.hatena.ne.jp/uskz/20080903/p6http://d.hatena.ne.jp/tanakahisateru/20090827/1251379409http://d.hatena.ne.jp/tanakahisateru/20090828/1251440513三項演算子と等価書き換えできない演算子になってなきゃいいけど。あれ?てか、そうなると、それはそれで評価順序が直感に反するような...。三項演算子のほうを変更するのかな?それとも、矛盾しててもいいのかな。Blog|ブログを報告する。