PHP 5.7と PHP7
前の手紙で述べたように、5.7はPHP7に直接切り替えることを支持して拒否されました。 これは、5.6と7の間に新しいバージョンが存在しないことを意味します。たとえそれが表示されたとしても、それはまだ古いコードに悩まされている人々へのシグナルとして機能します。 当初、5.7には新しい機能は搭載されていませんでしたが、コードの陳腐化に関する通知と警告をスローすることになっており、v7で間もなく変更されます。
また、PHP7で予約されているキーワードについて警告する必要があります。これにより、何らかの「自動」PHPバージョン互換性チェックを使用して、コードを迅速にコンプライアンスに準拠させることができます。 ただし、ニュースレターで書いたように、最新バージョンのPHPとの互換性を保つのに十分な能力を備えたほとんどの人は、PHP7が破損する可能性のある構造を実際には使用しません。
投票はあいまいですが、これはアイデアが最終的に埋もれていないことを示唆していることに注意してください。 参加者は、重大な変更がないため5.7に反対しますが、他のRFCでの新しい投票を考えると、考えを変えるかもしれません。 何が起こるか見てみましょう。
戻り型
圧倒的多数の票が投じられたため、PHPは最終的に戻り値の型を取得しました。 投票結果はまだ新鮮ですが、明確です。 PHP7以降、関数の正しい戻り値の型を最終的に指定できます。
function foo(): array { return []; }
改善？ 間違いなく!!! しかし、それは完璧ですか？ 残念ながらいいえ：
- 現在利用可能なタイプのみを返すことができます...
string
、int
、bool
などのスカラー値を返すことはできません。これは、同様の値を返すメソッドと関数が元の状態のままであることを意味します。
これは、同様の値のラッパーインスタンスを返すことで修正できますが、ほとんどの場合、これは不必要な倒錯です。 （おおよその車線-以前の取り組みの1つに注意を払う時です- プリミティブを通常のオブジェクトに変換します ） - 複数の型の戻り値を判別することはできません 関数が配列または
Iterator
オブジェクトのいずれかを返す場合、これを指定する方法はありません（たとえば、docブロックで行うようにarray|Iterator
。
一部の人々は、関数名の前ではなく、引数リストの閉じ括弧の後の型宣言について文句を言っていましたが、私にとってはピッキングです。 最新のC ++などの一般的な言語では、「post」構文を使用しますが、正規表現の変更に頼ることなく「function foo」を検索する機能を保持しています。 さらに、これはHHVMの使用と一貫性があるため、予期しない互換性ボーナスが発生します。
他の人はPHPの「厳格さ」について不満を述べていましたが、コメンテーターの一人が述べたように、コーディングを開始する前に、インターフェースを介して、他の人のコードを継承して、何を取得したいかを本当に知る必要があります。 さらに、戻り値の型の指定はオプションであり、その存在はPHPの全体的なパフォーマンスや安定性に影響を与えませんが、これから問題を膨らませる必要はありません。 このような機能について不平を言うことは、手続き型スパゲッティが問題を解決する良い方法であったときにPHPでOOPについて不平を言うことに似ています。 言語は進化しており、これは正しい方向へのステップの1つです。
どう思いますか？
アーティファクトの除去
次期バージョンでは、PHP4のスタイル構造を削除することを提案しています（まだ投票されていません）。 このRFCを読んで理解することができます。これは単純であり、繰り返す必要はありません。言語は前進します。 私は、そのようなステップが何人かの人々に非常に精神的な苦痛を引き起こす理由を理解しません。 たとえば、「言語を破壊しないでください」と削除された機能を何らかの意図で使用していると思われるトニーは尋ねます。
投稿は非常によく書かれており、明白な怒りにもかかわらず、そのようなコードベースがあまりにも長い間あるのではないかと思うようになりました。PHP7にアップグレードする価値はありますか？ そして、あなたが本当にそんなに欲しいなら、これをすべて一緒にドラッグする価値がありますか？壊れたクラスを特定し、コンストラクタを修正するのは簡単ではありませんか？ コードがテストで十分にカバーされていれば、このタスクを後任に委任することもでき、いつでも壊れていないことを確認できます。 また、テストがなくても、アプリケーションが理解できない品質のコードである場合、PHP7に移行するメリットを本当に望んでいますか？ 最初にアプリケーションを更新する方が良いと思いませんか？
「私が10年前に書いたコードは、今日でもまだ起動されており、10年で実行できるはずです」という文は-私にとってはおかしいです-確かに、1つからの移行の一部として、これをどんな人気のある言語からも期待すべきではありませんメインバージョンから別のバージョンへ。 現実の世界と平行して、今日は奴隷を持つ許可を期待すべきではありません。昔々、法律で許可されていたからです。 はい、血なまぐさい移行がありましたが、奴隷制の支持者の大部分が悔い改めるか亡くなったとき、平和が訪れました。
トニーに敬意を表する価値はあります。彼は彼の意見を擁護し、彼の会社の「ノー」が聞かれるように多くの努力をするのが正しいです。 しかし、長い目で見れば、今問題を取り除くだけの場合よりも、デザイナーと一緒に問題のトラブルシューティングを行うためのより多くの努力が必要になります。
メインバージョンですべてが正常のままであっても、互換性の破壊は常に一部の人々を混乱させることは明らかであり、互換性の破壊は進歩のために必要です。 そのような人々がそれについて学ぶときに上がるハウルを想像してください。 くそー、
mysql
代わりに
mysqli
が昨年更新されなかった場合、WordPressがPHP7で正常に動作しなかったか、コア開発者がWPユーザーに同情し、それらを残すことを決定した唯一の理由で、PHP7が穴だらけで絶望的に時代遅れになりました幸せです。
PHP7を恐れる人への私のアドバイスはやめます。 更新したくない場合は、これを行わないでください。 5.3または5.2に長い間座っていた場合（hello、CodeIgniterの愛好家）、さらに10年間5.6に座っていたとしても、PHPをモダンにしようとしないでください。 それを受け入れる準備ができている人に進行を任せてください。
これについてどう思いますか？ これはすべてうっかりしたアーティファクトの除去ですか、それとも本当に正しいステップですか？
余談：拡張APIの変更
興味深い周辺メモとして、PHP7にいくつかの変更があり、バージョン7への拡張機能の移植がわずかに遅れる場合があります。拡張機能を作成するためのAPIはリファクタリング（クリーニング）に該当し、すべてが変更される可能性がありますが、Sara Golemonからのこの刺激的なツイート少し注意を集めました。
くそー PHP7拡張APIの変更には重大な驚きがいくつかあります。 nothin 'ではありませんが、HHVMに切り替える良い機会です。
-SaraMG（@SaraMG） 2015年1月3日
彼女は基本的に、5.6から7に切り替えるときに拡張機能を作成する際の変更は非常に大きいため、HHVMで拡張機能を実行する方法を習得するのが簡単だと言います。 そして、彼女はHHVM拡張機能の作成方法に関する一連の記事でトピックの開発を続けています 。
拡張機能を開発していますか？ あなたは変化を研究しましたか、そしてこれらすべてについてどのように感じていますか？今の将来の効果について話すのは早すぎませんか？
編集 ：私の注意は、この後サラが HHVMとPHP7の両方と互換性のある新しい拡張API を文書化し始めたという事実に引き付けられました。 拡張機能を両方のランタイムと互換性があるようにできるようです！
おわりに
いつものように、PHPの世界はドラマに欠けていません。 すべての主要な革命と同様に、PHP7の歴史を通じて、驚くべきことが起こる前に血が流されます。 PHP7はまだ遠いので、マスケット銃の銃撃戦に巻き込まれたとしても、出口に出るのに十分な時間があります。 あなたが戦車の毛虫の下で眠るなら、両側はあなたを助けるためにほとんど何もすることができません。
これらのRFCについてどう思いますか？ 一般的なPHP7についてどう思いますか？ 彼は正しい方向に動いていますか？ 私たちに知らせてください-私たちはあなたの考えを聞きたいです！