PHP 7.4 リリース、プロパティの型やアロー関数が追加に 22
ストーリー by hylom
PHPもアロー関数導入なのか 部門より
PHPもアロー関数導入なのか 部門より
Anonymous Coward曰く、
11月29日、PHP 7.4がリリースされた（Phoronix）。
プロパティでの型指定や「=>」で関数を定義できる「アロー関数」の導入、配列スプレッド構文など、結構大規模な改善が入ったようだ。
Anonymous Coward曰く、
11月29日、PHP 7.4がリリースされた（Phoronix）。
プロパティでの型指定や「=>」で関数を定義できる「アロー関数」の導入、配列スプレッド構文など、結構大規模な改善が入ったようだ。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
日本語ソース (スコア:1)
日本語の情報もちらほら出てきたので貼っとく。
「PHP 7.4」リリース、型付けプロパティやアロー関数をサポート [mag.osdn.jp]
スクリプト言語「PHP 7.4」がリリース [impress.co.jp]
PHP 7.4公開 - 新機能導入と高速化 [mynavi.jp]
クロージャ書くのにいちいちfunctionって書くのだる過ぎたのでアロー関数は普通に嬉しい。っていうか今までよくみんな耐えられたな…。
Re: (スコア:0)
一番下、PHP7.5なんて初めて聞いたぞ
Re: (スコア:0)
7.4リリースなんだから、7.4のメンテナンス用ブランチができて
開発版はバージョン１つ上がって7.5になる。
ソフト開発してる人なら、言われなくても分かるし、言う必要も無い。
普通の事です。
Re:日本語ソース (スコア:1)
いや、PHP7.4の次のバージョンは8.0なんで
後藤大地だから (スコア:0)
mynavi / pcwatch は（責任）ライターの名前を出しているので、危ない記事かどうか、読む前に確認できてよいですね。
便利だけどクールじゃない仕様 (スコア:1)
Case Insensitive …… 言語構造、名前空間、クラス、関数
Case Sensitive …… 変数、配列キー、環境変数、プロパティ、メソッド、定数（定義による）
名前空間やクラスのオートローダー（読み込むパスの解決）はファイルシステムによる。
この辺の統一感の無さは、諦めるしかない。
const bool = 'hoge';
function bool() {
echo 'fuga';
}
echo bool; // hoge
bool(); // fuga
echo (bool) bool; // 1
予約語のような、そうでないような。
使われ方によって異なる実体（定数や関数やクラスや…）を指すのも、PHP の callable の闇の一因。
WordPress みたいな巨大システムでは、プラグイン A とプラグイン B が、同じライブラリの別バージョンをそれぞれ利用するケースがあっても、ハードコーディングされた名前空間（やクラスや関数）を動的に変えられないからコンフリクトを解消できない。
PHP に明るい未来はあるのだろうか？
名前統一してほしい (スコア:0)
最近色んな言語間で機能がやり取りされてる感じはあるけれど、同じ機能でも名前が違ったりすることがあるように見える。
(つまり、アロー関数じゃなくてラムダ式で良いじゃん。)
同一機能ならできるだけAPI(関数名とか)も揃えて欲しい。
(C#のLinqとJavaのStreamとか名前揃えて欲しい。)
その辺規格とかできないもんかな？
というか最初に実装したところが決めた名前でいいじゃん。
Re:名前統一してほしい (スコア:1)
C#は => をラムダ式で最初に採用した後、式で表現できる部分には大体適用できるように拡張しています。
// これはメソッド定義であってラムダ式ではない
public static double RadianToDegree(double radian) => radian * 180 / Math.PI;
で、これらを総称してexpression-bodied functionと言うそうな。もちろんこれはラムダ式より後に導入された名前。
Re:名前統一してほしい (スコア:1)
あとVB.Netなんかは「=>は使ってないけどラムダ式」になってるよね。
個人的にはアロー関数とラムダ式は一応別物だけど「アロー関数かつラムダ式」がけっこう多いからめんどくさいと認識してる。
うじゃうじゃ
Re:名前統一してほしい (スコア:1)
C/C++ 畑の自分としては、「アロー」といえば「->」なので分かりづらい……
そして Splatoon やっている身としては、「=>」はイカ速に見えてしまう……
Re: (スコア:0)
PHPにはC++由来の->もあるんだけどね。オブジェクト演算子って言うらしいね。
連想配列初期化の=>はダブルアロー演算子って言うみたいね。
でもラムダ式の=>はアロー関数なのか。
Re: (スコア:0)
メンバー変数 プロパティ変数 クラス変数 言い方はもっとたくさんあったがね。
Re: (スコア:0)
Stream APIのfilterやmapは関数型言語でよく使われてた名前から、LINQのselectやwhereはSQLからの類推と、出処がバラバラなんですよねえ
// LINQに慣れすぎてRubyの「select」でハマる
Re: (スコア:0)
SQLからの類推に見えても
・Whereの中で使っている列名が
（ほんとうのSQLならその場限りのローカル扱い）
・そのLINQを使っている場所で定義されている同名の
変数名とバッティングする
なんてSQLと違うのは確かで、
SQLっぽいのを止めるのは賛成！
Re: (スコア:0)
LINQなぁ、なんであんな仕様作ったのかさっぱり理解できない。
CollectionもRDB同じように扱えるっていうけど、同じように扱いたいか？
というか同じように扱っちゃダメだろと。
しかも直に扱うより思いっきりパフォーマンスも悪いし。パフォーマンス変わらないのならまだしも。
Re: (スコア:0)
ORMと同じような発想を裏返したプログラミングインターフェイスなんじゃないかね。
ORMはSQLの文法を知らなくても何となくメソッドチェインでそれなりに目的は達成される、
でもパフォーマンスを理解するには生成されるSQLを知っていなければならない。
一方LINQはSQLフレンドリーな記述をRDB以外のリソースに適用できる。
リソース毎に固有のインターフェースを知らなくても、何となく対象のリソース操作を行える。パフォーマンスの問題は同様。
まあ自分も正直、C#にクエリ式の文法は要らないんじゃないのと思う方だけど。
LINQの目指す所も分からないでもなく、LINQがラムダ式と型推論の早期導入を後押しした気がするから、
あまり嫌ってやらずにおいている感じ。
Re: (スコア:0)
LINQ to Objects (C#) [microsoft.com]
本質的に、LINQ to Objects は、コレクションを扱うための新しい方法です。 従来の方法では、複雑な foreach ループを記述して、コレクションからデータを取得する方法を指定する必要がありました。 LINQ を使用する場合は、何を取得するかを表す宣言コードを記述します。
また、LINQ クエリには、従来の foreach ループと比べて、次の 3 つの重要な利点があります。
Re: (スコア:0)
Collectionに対するシンタックスシュガーな拡張関数は便利でいいんだけどね。
こいつらはsystem.linq.dllを参照しなくとも使えるし。
性能は自分でごりごり書くのと結局同じだからな。書かずに済むので実にいい。
でもここで話しているLINQはSQLモドキのこと。
RDBだとSQLServer以外まともにつかえないんじゃね。
ODP.NETは対応してたと思うが使ってる奴なんて実際いるのかね？
Re: (スコア:0)
どうせ違う言語だと違う機能だと諦めてるから、名前だけ一緒だとかえって混乱する。
むしろ機能や実装を統一してもらった方が楽なことが……
三項演算子の結合規則が、一つだけ仲間ハズレの言語とかあるよね？
Re: (スコア:0)
バベルの塔
Re: (スコア:0)
ラムダ式は実装上ラムダではないからそれを明確にさせるための命名なんでラムダはラムダ（クロージャ）、
エンクロージャを保持する方法以外で実装されてるならラムダ式でいいのでは？
Re: (スコア:0)
> (C#のLinqとJavaのStreamとか名前揃えて欲しい。)
Stream(笑)みたいなゴミと一緒にされても困るんだが…