الجديد في PHP 8 (الميزات والتحسينات ومجمع JIT)

تم إصدار PHP 8 رسميًا للإتاحة العامة في 26 نوفمبر 2020!

يجلب هذا التحديث الرئيسي الجديد العديد من التحسينات والميزات القوية للغة. نحن متحمسون لإرشادك عبر التغييرات الأكثر إثارة للاهتمام التي ستسمح لنا بكتابة كود أفضل وإنشاء تطبيقات أكثر قوة.

إصدار PHP 8

ملحق إعلان PHP 8.0

PHP JIT (مترجم Just in Time)

الميزة الأكثر شهرة التي تأتي مع PHP 8 هي مترجم Just-in-time (JIT) . ما هو كل شيء عن JIT؟

يصف اقتراح RFC JIT على النحو التالي:

يتم تنفيذ PHP JIT كجزء شبه مستقل من OPcache. قد يتم تمكينه / تعطيله في وقت ترجمة PHP وفي وقت التشغيل. عند التمكين ، يتم تخزين الكود الأصلي لملفات PHP في منطقة إضافية من ذاكرة OPcache المشتركة و op_array → opcodes []. يحتفظ المعالج (المعالجات) بالمؤشرات إلى نقاط إدخال كود JIT-ed. “

إذن ، كيف وصلنا إلى JIT ، وما الفرق بين JIT و OPcache؟

لفهم ماهية JIT لـ PHP بشكل أفضل ، دعنا نلقي نظرة سريعة على كيفية تنفيذ PHP لشفرة المصدر حتى النتيجة النهائية.

تنفيذ PHP عبارة عن عملية من 4 مراحل:

التحويل البرمجي / التحويل البرمجي : أولاً ، يقرأ المترجم كود PHP ويبني مجموعة من الرموز المميزة.

التحليل : يتحقق المترجم مما إذا كان البرنامج النصي يطابق قواعد بناء الجملة ويستخدم الرموز المميزة لبناء شجرة بناء جملة مجردة (AST) ، وهو تمثيل هرمي لهيكل الكود المصدري .

التجميع : يجتاز المترجم الشجرة ويترجم عقد AST إلى أكواد تشغيل Zend منخفضة المستوى ، وهي معرفات رقمية تحدد نوع التعليمات التي يقوم بها Zend VM .

التفسير : يتم تفسير أكواد التشغيل وتشغيلها على Zend VM.

تُظهر الصورة التالية تمثيلاً مرئيًا لعملية تنفيذ PHP الأساسية.

عملية تنفيذ PHP الأساسية

عملية تنفيذ PHP الأساسية

إذن ، كيف تعمل OPcache على جعل PHP أسرع؟ وماذا يتغير في عملية التنفيذ مع JIT؟

ملحق OPcache

التحميل المسبق

JIT – مترجم Just in Time

ملحق OPcache

PHP هي لغة مفسرة. هذا يعني أنه عند تشغيل نص PHP ، يقوم المترجم بتحليل الشفرة وتجميعها وتنفيذها مرارًا وتكرارًا في كل طلب. قد يؤدي هذا إلى إهدار موارد وحدة المعالجة المركزية والوقت الإضافي.

هذا هو المكان الذي يأتي فيه ملحق OPcache للعب:

“يحسِّن OPcache أداء PHP من خلال تخزين كود نص برمجي مترجم مسبقًا في الذاكرة المشتركة ، وبالتالي إزالة الحاجة إلى PHP لتحميل النصوص البرمجية وتحليلها عند كل طلب.”

مع تمكين OPcache ، يمر مترجم PHP بعملية 4 مراحل المذكورة أعلاه فقط عندما يتم تشغيل البرنامج النصي لأول مرة. نظرًا لأنه يتم تخزين أكواد PHP bytecodes في الذاكرة المشتركة ، فهي متاحة على الفور كتمثيل متوسط ​​منخفض المستوى ويمكن تنفيذها على Zend VM على الفور.

عملية تنفيذ PHP مع تمكين OPcache

عملية تنفيذ PHP مع تمكين OPcache

اعتبارًا من PHP 5.5 ، يتوفر امتداد Zend OPcache افتراضيًا ، ويمكنك التحقق مما إذا كان قد تم تكوينه بشكل صحيح بمجرد الاتصالphpinfo() من برنامج نصي على الخادم الخاص بك أو التحقق من ملف php.ini (راجع إعدادات تكوين OPcache ).

قراءة مقترحة: كيفية تحسين حد ذاكرة PHP في وورد بريس .

قسم Zend OPcache في صفحة phpinfo

قسم Zend OPcache في صفحة phpinfo

التحميل المسبق

تم تحسين OPcache مؤخرًا من خلال تنفيذ التحميل المسبق ، وهي ميزة OPcache جديدة تمت إضافتها مع PHP 7.4 . يوفر التحميل المسبق طريقة لتخزين مجموعة محددة من البرامج النصية في ذاكرة OPcache ” قبل تشغيل أي رمز تطبيق. “ومع ذلك ، فإنه لا يجلب تحسينًا ملموسًا في الأداء للتطبيقات النموذجية المستندة إلى الويب.

يمكنك قراءة المزيد حول التحميل المسبق في مقدمتنا إلى PHP 7.4 .

باستخدام JIT ، تتحرك PHP خطوة إلى الأمام.

JIT – مترجم Just in Time

حتى إذا كانت أكواد التشغيل عبارة عن تمثيل متوسط ​​منخفض المستوى ، فلا يزال يتعين تجميعها في رمز الجهاز. JIT “لا يقدم أي نموذج IR (تمثيل متوسط) إضافي” ، ولكنه يستخدم DynASM (مجمع ديناميكي لمحركات توليد الكود) لإنشاء كود أصلي مباشرة من كود بايت PHP.

باختصار ، يترجم JIT الأجزاء الساخنة من الكود الوسيط إلى كود الآلة . تجاوز التجميع ، سيكون قادرًا على إحداث تحسينات كبيرة في الأداء واستخدام الذاكرة.

يوضح زئيف سوراسكي ، المؤلف المشارك لاقتراح PHP JIT ، مقدار العمليات الحسابية التي ستكون أسرع باستخدام JIT:

ولكن ، هل ستعمل JIT على تحسين أداء وورد بريس بشكل فعال ؟

JIT لتطبيقات الويب الحية

وفقًا لـ JIT RFC ، يجب أن يؤدي تطبيق المترجم في الوقت المناسب إلى تحسين أداء PHP. لكن هل سنشهد حقًا مثل هذه التحسينات في تطبيقات الحياة الواقعية مثل وورد بريس؟

تظهر الاختبارات المبكرة أن JIT ستجعل أحمال العمل كثيفة الاستخدام لوحدة المعالجة المركزية تعمل بشكل أسرع. ومع ذلك ، يحذر RFC :

“… مثل المحاولات السابقة – لا يبدو حاليًا أنه يحسن بشكل كبير تطبيقات الحياة الواقعية مثل وورد بريس (مع opcache.jit = 1235326 req / sec مقابل 315 req / sec).

من المخطط بذل جهد إضافي ، وتحسين JIT لتطبيقات الحياة الواقعية ، باستخدام تحسينات التنميط والمضاربة “.

مع تمكين JIT ، لن يتم تشغيل الكود بواسطة Zend VM ، ولكن بواسطة وحدة المعالجة المركزية نفسها ، مما يؤدي إلى تحسين سرعة الحساب. تطبيقات الويب مثل وورد يعتمد أيضا على عوامل أخرى مثل TTFB ، تحسين قاعدة البيانات ، HTTP طلبات ، الخ

مخطط أداء PHP 8

مساهمة JIT النسبية في أداء PHP 8 (مصدر الصورة: ملحق إعلان PHP 8.0 )

لذلك ، لا ينبغي أن نتوقع زيادة كبيرة في سرعة تنفيذ PHP عندما يتعلق الأمر بـ وورد بريس والتطبيقات المماثلة. ومع ذلك ، يمكن أن يجلب JIT العديد من الفوائد للمطورين .

وفقًا لنيكيتا بوبوف :

“فوائد مترجم JIT تقريبًا (كما هو موضح بالفعل في RFC):

أداء أفضل بشكل ملحوظ للرمز الرقمي.

أداء أفضل قليلاً لكود تطبيق ويب PHP “نموذجي”.

إمكانية نقل المزيد من التعليمات البرمجية من C إلى PHP ، لأن PHP ستكون الآن سريعة بما يكفي “.

لذلك ، في حين أن JIT بالكاد ستجلب تحسينات كبيرة على أداء وورد بريس ، فإنها ستعمل على ترقية PHP إلى المستوى التالي ، مما يجعلها لغة يمكن الآن كتابة العديد من الوظائف بها مباشرةً.

سيكون الجانب السلبي هو التعقيد الأكبر الذي يمكن أن يزيد من تكاليف الصيانة والاستقرار وتصحيح الأخطاء . بحسب ديمتري ستوجوف:

“JIT بسيط للغاية ، ولكنه على أي حال يزيد من مستوى تعقيد PHP بالكامل ، ومخاطر ظهور نوع جديد من الأخطاء وتكلفة التطوير والصيانة.”

تم تمرير اقتراح تضمين JIT في PHP 8 بأغلبية 50 صوتًا إلى صوتين.

PHP 8 هنا! 🚀 تحقق من الغوص العميق في الميزات الجديدة!

انقر للتغريد

تحسينات PHP 8 وميزات جديدة

بصرف النظر عن JIT ، يمكننا توقع العديد من الميزات والتحسينات مع PHP 8. القائمة التالية هي اختيارنا المختار بعناية للإضافات والتغييرات القادمة التي ستجعل PHP أكثر موثوقية وكفاءة.

ترويج ممتلكات المنشئ

التحقق من صحة طرق السمات المجردة

تواقيع أسلوب غير متوافق

المصفوفات التي تبدأ بمؤشر سلبي

أنواع الاتحاد 2.0

أخطاء متسقة من النوع للوظائف الداخلية

رمي التعبير

خرائط ضعيفة

فاصلة زائدة في قائمة المعلمات

السماح :: بناء جملة فئة على الكائنات

السمات v2

الحجج المسماة

مشغل Nullsafe

سلسلة Saner لمقارنات الأرقام

سلاسل رقمية سانر

مطابقة التعبير v2.0

عمليات التحقق من النوع الأكثر صرامة للعمليات الحسابية / المعامِلات على مستوى البت

ترويج ممتلكات المنشئ

كنتيجة للنقاش المستمر حول تحسين بيئة العمل للكائن في PHP ، يقترح Constructor Property Promotion RFC بنية جديدة وأكثر إيجازًا من شأنها تبسيط إعلان الخاصية ، مما يجعلها أقصر وأقل زائدة عن الحاجة.

هذا الاقتراح يتعلق فقط المعلمات الترويج ، أي تلك معلمات الأسلوب مسبوقة مع الجمهور ، محمية ، و خاصة الكلمات الرئيسية الرؤية.

حاليًا ، يجب تكرار جميع الخصائص عدة مرات (أربع مرات على الأقل) قبل أن نتمكن من استخدامها مع الكائنات. ضع في اعتبارك المثال التالي من RFC:

class Point {
    public int $x;
    public int $y;
    public int $z;

    public function __construct(
        int $x = 0,
        int $y = 0,
        int $z = 0,
    ) {
        $this->x = $x;
        $this->y = $y;
        $this->z = $z;
    }
}

وفقًا لنيكيتا بوبوف ، مؤلف RFC ، يتعين علينا كتابة اسم الخاصية أربع مرات على الأقل في ثلاثة أماكن مختلفة: إعلان الخاصية ، ومعلمات المُنشئ ، وتخصيص الخاصية. بناء الجملة هذا غير قابل للاستخدام بشكل خاص ، خاصة في الفئات التي تحتوي على العديد من الخصائص والأسماء الوصفية.

يقترح RFC هذا دمج المُنشئ وتعريف المعلمة. لذلك ، اعتبارًا من PHP 8 ، لدينا طريقة أكثر قابلية للاستخدام للإعلان عن المعلمات. يمكن تغيير الكود الموضح أعلاه كما هو موضح أدناه:

class Point {
    public function __construct(
        public int $x = 0,
        public int $y = 0,
        public int $z = 0,
    ) {}
}

وهذا كل شيء. لذلك لدينا طريقة جديدة للترويج للخصائص الأقصر ، والأكثر قابلية للقراءة ، والأقل عرضة للأخطاء. وفقا لنيكيتا :

إنه تحول نحوي بسيط نقوم به. لكن هذا يقلل من مقدار الشفرة المعيارية التي يجب عليك كتابتها للكائنات ذات القيمة على وجه الخصوص …

يتم تحويل إعلان الخاصية كما أعلنا صراحةً عن تلك الخصائص ، ويمكننا استخدام واجهة برمجة التطبيقات Reflection لاستبطان تعريفات الخاصية قبل التنفيذ (انظر Desugaring ):

التأمل (وآليات الاستبطان الأخرى) سوف يراقب الحالة بعد التنازل. هذا يعني أن الخصائص التي تمت ترقيتها ستظهر بنفس طريقة الخصائص المُعلنة صراحةً ، وستظهر وسيطات المُنشئ المُروَّجة كوسائط مُنشئ عادية.

// before desugaring
class Point {
    public function __construct(public int $x = 0) {}
}

// after desugaring
class Point {
    public int $x;

    public function __construct(int $x = 0) {
        $this->x = $x;
    }
}

ميراث

ليس لدينا أي قيود في استخدام الوراثة بالتزامن مع المعلمات التي تمت ترقيتها. على أي حال ، لا توجد علاقة معينة بين مُنشئي فئة الوالدين والطفل. وفقا لنيكيتا :

عادة ، نقول أن الأساليب يجب أن تكون دائمًا متوافقة مع طريقة الوالدين. […] لكن هذه القاعدة لا تنطبق على المنشئ. لذا فإن المُنشئ ينتمي حقًا إلى فئة واحدة ، ولا يجب أن تكون المنشئات بين فئة الأصل والطبقة الفرعية متوافقة بأي شكل من الأشكال.

هنا مثال:

class Test {
    public function __construct(
        public int $x = 0
    ) {}
}

class Child extends Test {
    public function __construct(
        $x, 
        public int $y = 0,
        public int $z = 0,
    ) {
        parent::__construct($x);
    }
}

ما هو غير مسموح به مع الخصائص التي يتم الترويج لها

يُسمح بالخصائص التي يتم الترويج لها في المنشئات والسمات غير المجردة ، ولكن هناك العديد من القيود الجديرة بالذكر هنا.

بانيو مجردة

الخصائص التي تمت ترقيتها غير مسموح بها في الفئات والواجهات المجردة:

abstract class Test {
    // Error: Abstract constructor.
    abstract public function __construct(private $x);
}
 
interface Test {
    // Error: Abstract constructor.
    public function __construct(private $x);
}

بطلان

واحدة من أبرز القيود المتعلقة بالإلغاء. في السابق ، استخدمنا نوعًا لم يكن قابلاً للإلغاء بشكل صريح. ولكن مع وجود قيمة افتراضية خالية ، كان النوع لاغيًا ضمنيًا. ولكن مع أنواع الخصائص ، ليس لدينا هذا السلوك الضمني لأن المعلمات التي تمت ترقيتها تتطلب إعلانًا عن الخاصية ، ويجب التصريح عن النوع nullable بشكل صريح. انظر المثال التالي من RFC:

class Test {
    // Error: Using null default on non-nullable property
    public function __construct(public Type $prop = null) {}

    // Correct: Make the type explicitly nullable instead
    public function __construct(public ?Type $prop = null) {}
}

النوع القابل للاستدعاء

نظرًا لأن Callable ليس نوعًا مدعومًا للخصائص ، فلا يُسمح لنا باستخدام النوع القابل للاستدعاء في الخصائص التي تمت ترقيتها:

class Test {
    // Error: Callable type not supported for properties.
    public function __construct(public callable $callback) {}
}

كلمة var غير مسموح بها

يمكن استخدام كلمة رئيسية فقط مع المعلمات المروجة ، لذلك varلا يُسمح بإعلان خصائص المُنشئ بالكلمة الرئيسية (انظر المثال التالي من RFC):

class Test {
    // Error: "var" keyword is not supported.
    public function __construct(var $prop) {}
}

لا يسمح الازدواجية

يمكننا الجمع بين الخصائص التي تمت ترقيتها والخصائص الصريحة في نفس الفئة ، ولكن لا يمكن التصريح عن الخصائص مرتين:

class Test {
    public string $prop;
    public int $explicitProp;

    // Correct
    public function __construct(public int $promotedProp, int $arg) {
        $this->explicitProp = $arg;
    }

    // Error: Redeclaration of property.
    public function __construct(public string $prop) {}
}

لا يُسمح بالمعلمات المتغيرة

السبب هنا هو أن النوع المُعلن يختلف عن المُعامل المتغير ، وهو في الواقع مصفوفة:

class Test {
    // Error: Variadic parameter.
    public function __construct(public string ...$strings) {}
}

قراءات إضافية

للحصول على عرض أقرب في Costructor Property Promotion ، استمع إلى هذه المقابلة مع نيكيتا بوبوف . للحصول على نظرة عامة متعمقة حول بيئة عمل الكائن في PHP ، راجع هذا المنشور والمقابلة التالية مع Larry Garfield .

التحقق من صحة طرق السمات المجردة

تُعرَّف السمات على أنها “آلية لإعادة استخدام الكود في لغات الوراثة الفردية مثل PHP”. عادةً ما يتم استخدامها للإعلان عن الطرق التي يمكن استخدامها في فئات متعددة.

يمكن أن تحتوي السمة أيضًا على طرق مجردة. تعلن هذه الطرق ببساطة عن توقيع الطريقة ، لكن تنفيذ الطريقة يجب أن يتم داخل الفصل باستخدام السمة.

وفقًا لدليل PHP ،

“السمات تدعم استخدام الأساليب المجردة من أجل فرض متطلبات على فئة العارضين.”

هذا يعني أيضًا أن تواقيع الطرق يجب أن تتطابق. بمعنى آخر ، يجب أن يكون نوع وعدد الوسائط المطلوبة هو نفسه .

على أي حال ، وفقًا لنيكيتا بوبوف ، مؤلف RFC ، لا يتم فرض التحقق من صحة التوقيع حاليًا إلا بشكل مفاجئ:

لا يتم فرضه في الحالة الأكثر شيوعًا ، حيث يتم توفير تنفيذ الطريقة بواسطة فئة الاستخدام : https://3v4l.org/SeVK3

يتم فرضه إذا كان التنفيذ يأتي من فئة رئيسية: https://3v4l.org/4VCIp

يتم فرضه إذا كان التنفيذ يأتي من فئة فرعية : https://3v4l.org/q7Bq2

المثال التالي من نيكيتا يتعلق بالحالة الأولى (التوقيع غير المفروض):

trait T {
	abstract public function test(int $x);
}
 
class C {
	use T;

	// Allowed, but shouldn't be due to invalid type.
	public function test(string $x) {}
}

مع ما يقال ، يقترح RFC هذا دائمًا إلقاء خطأ فادح إذا كانت طريقة التنفيذ غير متوافقة مع طريقة السمات المجردة ، بغض النظر عن أصلها:

Fatal error: Declaration of C::test(string $x) must be compatible with T::test(int $x) in /path/to/your/test.php on line 10

تمت الموافقة على طلب التعليقات هذا بالإجماع.

تواقيع أسلوب غير متوافق

في PHP ، تؤدي أخطاء الوراثة الناتجة عن تواقيع الطريقة غير المتوافقة إلى حدوث خطأ فادح أو تحذير بناءً على سبب الخطأ.

إذا كانت إحدى الفئات تقوم بتنفيذ واجهة ، فإن تواقيع الطريقة غير المتوافقة تؤدي إلى حدوث خطأ فادح. وفقًا لوثائق واجهات الكائنات :

“يجب أن تستخدم الفئة التي تنفذ الواجهة توقيع أسلوب متوافق مع LSP (مبدأ استبدال Liskov). عدم القيام بذلك سيؤدي إلى خطأ فادح “.

فيما يلي مثال على خطأ وراثي بواجهة :

interface I {
	public function method(array $a);
}
class C implements I {
	public function method(int $a) {}
}

في الإصدار 7.4 من PHP ، سيظهر الرمز أعلاه الخطأ التالي:

Fatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in /path/to/your/test.php on line 7

وظيفة في فئة فرعية ذات توقيع غير متوافق ستلقي تحذيرًا. انظر الكود التالي من RFC:

class C1 {
	public function method(array $a) {}
}
class C2 extends C1 {
	public function method(int $a) {}
}

في PHP 7.4 ، فإن الكود أعلاه سيرسل ببساطة تحذيرًا:

Warning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in /path/to/your/test.php on line 7

الآن ، يقترح RFC هذا دائمًا إلقاء خطأ فادح لتوقيعات الطريقة غير المتوافقة. مع PHP 8 ، سيطلب الكود الذي رأيناه سابقًا ما يلي:

Fatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in /path/to/your/test.php on line 7

المصفوفات التي تبدأ بمؤشر سلبي

في PHP ، إذا بدأت المصفوفة بمؤشر سالب ( start_index < 0) ، فستبدأ المؤشرات التالية من 0 (المزيد حول هذا في array_fillالتوثيق ). ننظر إلى المثال التالي:

$a = array_fill(-5, 4, true);
var_dump($a);

في PHP 7.4 ، ستكون النتيجة كما يلي:

array(4) {
	[-5]=>
	bool(true)
	[0]=>
	bool(true)
	[1]=>
	bool(true)
	[2]=>
	bool(true)
}

الآن ، يقترح RFC هذا تغيير الأشياء بحيث يكون المؤشر الثاني start_index + 1، أيهما قيمة start_index.

في PHP 8 ، ينتج عن الكود أعلاه المصفوفة التالية:

array(4) {
	[-5]=>
	bool(true)
	[-4]=>
	bool(true)
	[-3]=>
	bool(true)
	[-2]=>
	bool(true)
}

مع PHP 8 ، فإن المصفوفات التي تبدأ بمؤشر سلبي تغير سلوكها. اقرأ المزيد حول حالات عدم التوافق السابقة في RFC .

أنواع الاتحاد 2.0

تقبل أنواع الاتحاد القيم التي يمكن أن تكون من أنواع مختلفة. حاليًا ، لا توفر PHP دعمًا لأنواع الاتحاد ، باستثناء ?Typeبناء الجملة iterableوالنوع الخاص .

قبل PHP 8 ، كان من الممكن تحديد أنواع الاتحاد فقط في تعليقات phpdoc ، كما هو موضح في المثال التالي من RFC:

class Number {

            /**

class Number {
	/**
	 * @var int|float $number
	 */
	private $number;

	/**
	 * @param int|float $number
	 */
	public function setNumber($number) {
		$this->number = $number;
	}

	/**
	 * @return int|float
	 */
	public function getNumber() {
		return $this->number;
	}
}

الآن ، تقترح أنواع الاتحاد 2.0 RFC إضافة دعم لأنواع الاتحاد في تواقيع الوظائف ، حتى لا نعتمد على الوثائق المضمنة بعد الآن ، ولكننا نحدد أنواع الاتحاد مع T1|T2|…بناء جملة بدلاً من ذلك:

class Number {
	private int|float $number;

	public function setNumber(int|float $number): void {
		$this->number = $number;
	}

	public function getNumber(): int|float {
		return $this->number;
	}
}

كما أوضح نيكيتا بوبوف في RFC ،

“يتيح لنا دعم أنواع الاتحاد في اللغة نقل المزيد من معلومات الكتابة من phpdoc إلى توقيعات الوظائف ، مع المزايا المعتادة التي يجلبها هذا:

يتم فرض الأنواع في الواقع ، لذلك يمكن اكتشاف الأخطاء مبكرًا.

نظرًا لأنه يتم فرضها ، فمن غير المرجح أن تصبح معلومات الكتابة قديمة أو تفقد حالات الحافة.

يتم فحص الأنواع أثناء الوراثة ، وفرض مبدأ استبدال Liskov.

أنواع متاحة من خلال انعكاس.

بناء الجملة أقل بكثير من لغة pilerplate من phpdoc “.

تدعم أنواع الاتحاد جميع الأنواع المتاحة ، مع بعض القيود:

و voidنوع لا يمكن أن تكون جزءا من الاتحاد، كما voidيعني أن وظيفة لا يرجع أي قيمة .

و nullيتم اعتماد نوع فقط في أنواع اتحاد ولكن لا يسمح انها الاستخدام كنوع مستقل.

?Tيُسمح أيضًا بتدوين النوع nullable ( ) ، بمعنى T|null، لكن لا يُسمح لنا بتضمين ?Tالترميز في أنواع الاتحاد ( ?T1|T2غير مسموح به ويجب أن نستخدمه T1|T2|nullبدلاً من ذلك).

كما العديد من المهام (أي strpos()، strstr()، substr()، الخ) تشمل falseمن بين أنواع عائد ممكن، و falseكما يدعم الزائفة نوع.

يمكنك قراءة المزيد عن Union Types V2 في RFC.

أخطاء متسقة من النوع للوظائف الداخلية

عند تمرير معلمة من نوع غير قانوني، الداخلية و المعرفة من قبل المستخدم وظائف تتصرف بشكل مختلف.

تطرح الوظائف المعرفة من قبل المستخدم TypeError، لكن الوظائف الداخلية تتصرف بطرق مختلفة ، اعتمادًا على عدة شروط. على أي حال ، فإن السلوك المعتاد هو إلقاء تحذير والعودة null. راجع المثال التالي في PHP 7.4:

var_dump(strlen(new stdClass));

سينتج عن هذا التحذير التالي:

Warning: strlen() expects parameter 1 to be string, object given in /path/to/your/test.php on line 4
NULL

إذا strict_typesتم تمكينه ، أو تحدد معلومات الوسيطة أنواعًا ، فسيكون السلوك مختلفًا. في مثل هذه السيناريوهات ، يتم اكتشاف خطأ النوع وينتج عنه ملف TypeError.

قد يؤدي هذا الموقف إلى عدد من المشكلات الموضحة جيدًا في قسم مشكلات RFC .

لإزالة هذه التناقضات ، يقترح RFC هذا جعل المعلمة الداخلية لتحليل واجهات برمجة التطبيقات لإنشاء دائمًا ThrowErrorفي حالة عدم تطابق نوع المعلمة.

في PHP 8 ، يلقي الكود أعلاه الخطأ التالي:

Fatal error: Uncaught TypeError: strlen(): Argument #1 ($str) must be of type string, object given in /path/to/your/test.php:4
Stack trace:
#0 {main}
  thrown in /path/to/your/test.php on line 4

رمي التعبير

في PHP، throwهو بيان ، لذلك فمن غير الممكن استخدامها في الأماكن التي يكون فيها سوى التعبير مسموح به.

تريد أن تعرف كيف زدنا من حركة المرور لدينا أكثر من 1000 ٪؟

انضم إلى أكثر من 20000 آخرين ممن يتلقون رسائلنا الإخبارية الأسبوعية مع نصائح من الداخل حول وورد بريس!

إشترك الآن

يقترح RFC هذا تحويل throwالعبارة إلى تعبير بحيث يمكن استخدامه في أي سياق يُسمح فيه بالتعبيرات. على سبيل المثال، السهم وظائف ، مشغل تتجمع لاغيا ، الثلاثي والفيس المشغلين ، الخ

انظر الأمثلة التالية من RFC:

$callable = fn() => throw new Exception();

// $value is non-nullable.
$value = $nullableValue ?? throw new InvalidArgumentException();
 
// $value is truthy.
$value = $falsableValue ?: throw new InvalidArgumentException();

خرائط ضعيفة

الخريطة الضعيفة هي مجموعة بيانات (كائنات) يتم فيها الإشارة إلى المفاتيح بشكل ضعيف ، مما يعني أنه لا يتم منعها من جمع البيانات غير الهامة.

أضاف PHP 7.4 دعمًا للمراجع الضعيفة كطريقة للاحتفاظ بمرجع إلى كائن لا يمنع تدمير الكائن نفسه. كما أشار نيكيتا بوبوف ،

“المراجع الضعيفة الخام ليست سوى ذات فائدة محدودة في حد ذاتها ، والخرائط الضعيفة أكثر شيوعًا في الممارسة العملية. لا يمكن تنفيذ خريطة ضعيفة فعالة فوق مراجع PHP الضعيفة لأن القدرة على تسجيل رد اتصال التدمير غير متوفرة “.

لهذا السبب تقدم RFCWeakMap فئة لإنشاء كائنات لاستخدامها كمفاتيح خرائط ضعيفة يمكن تدميرها وإزالتها من الخريطة الضعيفة إذا لم تكن هناك أي إشارات أخرى إلى الكائن الرئيسي.

في العمليات طويلة المدى ، سيمنع هذا تسرب الذاكرة ويحسن الأداء. انظر المثال التالي من RFC:

$map = new WeakMap;
$obj = new stdClass;
$map[$obj] = 42;
var_dump($map);

باستخدام PHP 8 ، ينتج عن الكود أعلاه النتيجة التالية (انظر التعليمات البرمجية قيد التشغيل هنا ):

object(WeakMap)#1 (1) {
	[0]=>
	array(2) {
		["key"]=>
		object(stdClass)#2 (0) {
		}
		["value"]=>
		int(42)
	}
}

إذا قمت بإلغاء تحديد الكائن ، فسيتم إزالة المفتاح تلقائيًا من الخريطة الضعيفة:

unset($obj);
var_dump($map);

الآن ستكون النتيجة كما يلي:

object(WeakMap)#1 (0) {
}

لإلقاء نظرة فاحصة على الخرائط الضعيفة ، راجع RFC . تمت الموافقة على الاقتراح بالإجماع.

فاصلة زائدة في قائمة المعلمات

يتم إلحاق الفاصلات اللاحقة بقوائم العناصر في سياقات مختلفة. قدمت PHP 7.2 فواصل لاحقة في بناء جملة القائمة ، بينما قدمت PHP 7.3 فواصل لاحقة في استدعاءات الوظائف .

تقدم PHP 8 الآن فاصلات لاحقة في قوائم المعلمات بالوظائف والطرق والإغلاق ، كما هو موضح في المثال التالي:

class Foo {
	public function __construct(
		string $x,
		int $y,
		float $z, // trailing comma
	) {
		// do something
	}
}

تم تمرير هذا الاقتراح بأغلبية 58 صوتًا مقابل 1.

السماح :: بناء جملة فئة على الكائنات

لجلب اسم الفصل ، يمكننا استخدام Foo\Bar::classبناء الجملة. يقترح RFC هذا تمديد نفس بناء الجملة للكائنات بحيث أصبح من الممكن الآن جلب اسم فئة كائن معين ، كما هو موضح في المثال أدناه:

$object = new stdClass;
var_dump($object::class); // "stdClass"
 
$object = null;
var_dump($object::class); // TypeError

مع PHP 8 ، يتم $object::classتوفير نفس النتيجة مثل get_class($object). إذا $objectلم يكن كائنًا ، فإنه يطرح TypeErrorاستثناءً.

تمت الموافقة على هذا الاقتراح بالإجماع.

السمات v2

السمات ، المعروفة أيضًا باسم التعليقات التوضيحية ، هي بيانات وصفية منظمة يمكن استخدامها لتحديد خصائص الكائنات أو العناصر أو الملفات.

حتى PHP 7.4 ، كانت تعليقات المستندات هي الطريقة الوحيدة لإضافة البيانات الوصفية إلى إعلانات الفئات والوظائف وما إلى ذلك. تقدم Attributes v2 RFC سمات PHP ، وتعرفها على أنها شكل من أشكال البيانات الوصفية الهيكلية والنحوية التي يمكن إضافتها إلى إعلانات الفئات ، الخصائص والوظائف والطرق والمعلمات والثوابت.

تُضاف السمات قبل الإعلانات التي تشير إليها. انظر الأمثلة التالية من RFC:

<<ExampleAttribute>>
class Foo
{
	<<ExampleAttribute>>
	public const FOO = 'foo';

	<<ExampleAttribute>>
	public $x;

	<<ExampleAttribute>>
	public function foo(<<ExampleAttribute>> $bar) { }
}

$object = new <<ExampleAttribute>> class () { };

<<ExampleAttribute>>
function f1() { }

$f2 = <<ExampleAttribute>> function () { };

$f3 = <<ExampleAttribute>> fn () => 1;

يمكن إضافة السمات قبل أو بعد تعليق حظر المستند:

<<ExampleAttribute>>
/** docblock */
<<AnotherExampleAttribute>>
function foo() {}

قد يحتوي كل إعلان على سمة واحدة أو أكثر ، وقد تحتوي كل سمة على قيمة مرتبطة واحدة أو أكثر:

<<WithoutArgument>>
<<SingleArgument(0)>>
<<FewArguments('Hello', 'World')>>
function foo() {}

راجع RFC للحصول على نظرة عامة أكثر تفصيلاً لسمات PHP وحالات الاستخدام والصياغة البديلة.

الحجج المسماة

توفر الوسيطات المسماة طريقة جديدة لتمرير الوسائط إلى دالة في PHP:

تسمح الوسائط المسماة بتمرير الوسائط إلى دالة بناءً على اسم المعلمة ، بدلاً من موضع المعلمة.

يمكننا تمرير الوسائط المسماة إلى دالة عن طريق إضافة اسم المعلمة قبل قيمتها:

callFunction(name: $value);

يُسمح لنا أيضًا باستخدام الكلمات الرئيسية المحجوزة ، كما هو موضح في المثال أدناه:

callFunction(array: $value);

لكن لا يُسمح لنا بتمرير اسم المعلمة ديناميكيًا. يجب أن تكون المعلمة معرّفًا ، ولا يُسمح بالصياغة التالية :

callFunction($name: $value);

وفقًا لنيكيتا بوبوف ، مؤلف هذا RFC ، تقدم الحجج المسماة العديد من المزايا.

أولاً ، ستساعدنا الوسيطات المسماة على كتابة كود أكثر قابلية للفهم لأن معناها هو التوثيق الذاتي. المثال أدناه من RFC واضح بذاته:

array_fill(start_index: 0, num: 100, value: 50);

الوسائط المسماة مستقلة عن النظام. هذا يعني أننا لسنا مجبرين على تمرير الوسائط إلى دالة بنفس ترتيب توقيع الوظيفة:

array_fill(value: 50, num: 100, start_index: 0);

من الممكن أيضًا دمج الحجج المسماة مع الحجج الموضعية:

هل تحتاج إلى استضافة سريعة وآمنة وصديقة للمطورين لمواقعك؟ تم تصميم Kinsta مع وضع مطوري وورد بريس في الاعتبار ويوفر الكثير من الأدوات ولوحة تحكم قوية. تحقق من خططنا

htmlspecialchars($string, double_encode: false);

ميزة أخرى رائعة للحجج المسماة أنها تسمح فقط بتحديد تلك الحجج التي نريد تغييرها. لا يتعين علينا تحديد الوسائط الافتراضية إذا كنا لا نريد استبدال القيم الافتراضية. يوضح المثال التالي من RFC الأمر:

htmlspecialchars($string, default, default, false);
// vs
htmlspecialchars($string, double_encode: false);

الأهمية

إذا كنت مطور وورد بريس ، فيرجى ملاحظة أنه في وقت كتابة هذا التقرير ، قد تؤدي الوسائط المسماة إلى مشكلات التوافق مع الإصدارات السابقة . لا تستخدمها في الإنتاج بدون اختبار مدروس.

يمكن استخدام الوسائط المسماة مع سمات PHP ، كما هو موضح في المثال التالي من RFC:

<<MyAttribute('A', b: 'B')>>
class Test {}

ومع ذلك ، لا يُسمح بتمرير الوسائط الموضعية بعد الوسائط المسماة وسيؤدي ذلك إلى حدوث خطأ في وقت الترجمة. يحدث الشيء نفسه عند تمرير نفس اسم المعلمة مرتين.

الوسيطات المسماة سهلة الاستخدام مع إعلانات الفئة لأن المنشئات عادة ما تحتوي على العديد من المعلمات ، وتوفر الوسيطات المسماة طريقة أكثر “مريحة” للإعلان عن فئة.

للحصول على عرض أقرب في Named Arguments ، مع القيود وعدم التوافق مع الإصدارات السابقة والعديد من الأمثلة ، راجع RFC Arguments المسماة .

مشغل Nullsafe

يقدم هذا RFC المشغل nullsafe بتقييم $->كامل للدارة القصيرة .

في تقييم الدارة القصيرة ، لا يتم تقييم العامل الثاني إلا إذا لم يقم المشغل الأول بتقييمه null. إذا قام عامل في سلسلة بالتقييم لـ null، فإن تنفيذ السلسلة بأكملها يتوقف ويقيم null.

خذ بعين الاعتبار الأمثلة التالية من RFC:

$foo = $a?->b();

إذا كانت القيمة $aخالية ، b()فلن يتم استدعاء الطريقة $fooويتم تعيينها على null.

راجع عامل التشغيل nullsafe RFC للحصول على أمثلة إضافية واستثناءات ونطاق مستقبلي.

سلسلة Saner لمقارنات الأرقام

في إصدارات PHP السابقة ، عند إجراء مقارنة غير صارمة بين السلاسل والأرقام ، تقوم PHP أولاً بنقل السلسلة إلى رقم ، ثم تقوم بإجراء المقارنة بين الأعداد الصحيحة أو العائمة. حتى إذا كان هذا السلوك مفيدًا جدًا في العديد من السيناريوهات ، فقد ينتج عنه نتائج خاطئة قد تؤدي أيضًا إلى أخطاء و / أو مشكلات أمنية.

ضع في اعتبارك المثال التالي من RFC:

$validValues = ["foo", "bar", "baz"];
$value = 0;
var_dump(in_array($value, $validValues));
// bool(true)

تقدم PHP 8 سلسلة Saner إلى مقارنات بين الأرقام ، بهدف جعل المقارنات بين الأعداد أكثر منطقية. على حد تعبير نيكيتا بوبوف ،

يهدف RFC هذا إلى إعطاء مقارنات سلسلة إلى رقم سلوكًا أكثر منطقية: عند المقارنة بسلسلة رقمية ، استخدم مقارنة رقم (كما هو الحال الآن). خلاف ذلك ، قم بتحويل الرقم إلى سلسلة واستخدم مقارنة السلسلة.

يقارن الجدول التالي سلوك السلسلة بأرقام مقارنة إصدارات PHP السابقة وفي PHP 8:

مقارنة | قبل | بعد، بعدما
------------------------------
 0 == "0" | صحيح | حقيقية
 0 == "0.0" | صحيح | حقيقية
 0 == "foo" | صحيح | خطأ 
 0 == "" | صحيح | خاطئة
42 == "42" | صحيح | حقيقية
42 == "42foo" | صحيح | خاطئة

اقرأ المزيد حول الآثار العديدة لهذا التغيير وكيف تتغير مقارنات الأعداد في PHP 8 في RFC الرسمي من Nikita Popov .

سلاسل رقمية سانر

في PHP ، تنقسم السلاسل التي تحتوي على أرقام إلى ثلاث فئات :

سلاسل رقمية : سلاسل تحتوي على رقم تسبقه مسافات بشكل اختياري.

السلسلة الرقمية البادئة : السلاسل التي تكون أحرفها الأولية عبارة عن سلاسل رقمية والأحرف اللاحقة غير رقمية.

سلسلة غير رقمية : سلاسل لا تقع في أي من الفئات السابقة.

يتم التعامل مع السلاسل الرقمية والسلاسل الرقمية البادئة بشكل مختلف بناءً على العملية التي يتم إجراؤها. على سبيل المثال:

سلسلة واضحة لتحويل عدد (أي (int)و (float)نوع يلقي) الرقمية وتحويل أرقام سلاسل الرائدة رقمية. تحويل سلسلة غير رقمية بشكل صريح إلى رقم ينتج 0.

تؤدي السلسلة الضمنية إلى تحويلات الأرقام (أي عدم strict_typeالإعلان) إلى نتائج مختلفة للسلاسل الرقمية وغير الرقمية. سلسلة غير رقمية للتحويلات الرقمية تطرح ملف TypeError.

is_numeric()إرجاع صحيح فقط للسلاسل الرقمية.

تؤدي إزاحة السلاسل ، والعمليات الحسابية ، وعمليات الزيادة والنقصان ، والمقارنات من سلسلة إلى سلسلة ، والعمليات الأحادية أيضًا إلى نتائج مختلفة.

يقترح طلب التعليقات هذا :

توحيد أوضاع السلسلة الرقمية المختلفة في مفهوم واحد: الأحرف الرقمية فقط مع السماح بالمسافة البيضاء البادئة واللاحقة. أي نوع آخر من السلاسل هو غير رقمي وسيرمي TypeErrors عند استخدامه في سياق رقمي.

هذا يعني أن جميع السلاسل التي تصدر حاليًا E_NOTICE “تمت مصادفة قيمة رقمية غير جيدة التكوين” سيتم إعادة تصنيفها في E_WARNING “تمت مصادفة قيمة غير رقمية” إلا إذا كانت السلسلة الرقمية البادئة تحتوي على مسافة بيضاء لاحقة فقط. وستتم ترقية الحالات المختلفة التي تنبعث منها حاليًا رسالة إلكترونية E_WARNING إلى TypeErrors.

للحصول على نظرة عامة أكثر تعمقًا على السلاسل الرقمية في PHP 8 ، مع أمثلة التعليمات البرمجية والاستثناءات ومشكلات التوافق مع الإصدارات السابقة ، راجع RFC .

مطابقة التعبير v2.0

matchيتشابه التعبير الجديد إلى حد كبير switchمع الدلالات الأكثر أمانًا ولكن مع السماح بإرجاع القيم.

لفهم الاختلاف بين بنيتي التحكم ، ضع في اعتبارك switchالمثال التالي من RFC :

switch (1) {
	case 0:
		$result = 'Foo';
		break;
	case 1:
		$result = 'Bar';
		break;
	case 2:
		$result = 'Baz';
		break;
}
 
echo $result;
//> Bar

يمكننا الآن الحصول على نفس نتيجة الكود أعلاه matchبالتعبير التالي :

echo match (1) {
	0 => 'Foo',
	1 => 'Bar',
	2 => 'Baz',
};
//> Bar

من المزايا المهمة لاستخدام matchالتعبير الجديد أنه بينما switchيقارن القيم بشكل فضفاض ( ==) يحتمل أن يؤدي إلى نتائج غير متوقعة ، مع matchالمقارنة هي التحقق من الهوية ( ===).

و matchقد يحتوي التعبير أيضا عدة عبارات مفصولة بفواصل السماح لمزيد من جملة موجزة ( مصدر ):

$result = match ($x) {
	// This match arm:
	$a, $b, $c => 5,
	// Is equivalent to these three match arms:
	$a => 5,
	$b => 5,
	$c => 5,
};

للحصول على أمثلة وحالات الاستخدام إضافية، راجع التعبير المباراة V2 RFC و ثائق PHP .

عمليات التحقق من النوع الأكثر صرامة للعمليات الحسابية / المعامِلات على مستوى البت

في الإصدارات السابقة PHP، وتطبيق الحسابية و المختصة بالبت المشغلين لمجموعة، الموارد، أو كائن غير مثقلة سمح. على أي حال ، كان السلوك في بعض الأحيان غير متسق.

في RFC هذا ، يوضح نيكيتا بوبوف كيف يمكن أن يكون هذا السلوك غير معقول بمثال بسيط:

var_dump([] % [42]);
// int(0)

يشرح نيكيتا كيف أدى تطبيق المعامل الحسابي أو المعامل على المصفوفات أو الموارد أو الكائنات غير المحملة بشكل زائد إلى نتائج مختلفة :

عوامل التشغيل +، -، *، /، **:

طرح استثناء خطأ في معامل الصفيف. (باستثناء + إذا كان كلا المعاملين عبارة عن صفيف).

بصمت تحويل معامل المورد إلى معرّف المورد كعدد صحيح.

تحويل معامل الكائن إلى عدد صحيح واحد ، أثناء إلقاء إشعار.

عوامل التشغيل٪ ، << ، >> ، & ، | ، ^:

قم بتحويل معامل المصفوفة بصمت إلى عدد صحيح صفر إذا كان فارغًا أو إذا كان عددًا صحيحًا واحدًا إذا لم يكن فارغًا.

بصمت تحويل معامل المورد إلى معرّف المورد كعدد صحيح.

تحويل معامل الكائن إلى عدد صحيح واحد ، أثناء إلقاء إشعار.

عامل التشغيل ~:

قم بطرح استثناء خطأ لمعاملات الصفيف والمورد والكائن.

المشغلين ++ و -:

لا تفعل شيئًا بصمت إذا كان المعامل عبارة عن مصفوفة أو مورد أو كائن.

مع PHP 8 ، تتغير الأشياء ، والسلوك هو نفسه لجميع العمليات الحسابية والخاصة بالبت:

قم بطرح TypeErrorاستثناء لمعاملات الصفيف والمورد والكائن.

وظائف PHP جديدة

يجلب PHP 8 العديد من الوظائف الجديدة إلى اللغة:

str_contains

str_starts_with () و str_ends_with ()

get_debug_type

str_contains

قبل PHP 8 ، كانت strstr و strpos هي الخيارات النموذجية للمطورين للبحث عن إبرة داخل سلسلة معينة. تكمن المشكلة في أن كلتا الوظيفتين لا تعتبر بديهية للغاية ، ويمكن أن يكون استخدامهما مربكًا لمطوري PHP الجدد. انظر المثال التالي:

$mystring = 'Managed WordPress Hosting';
$findme = 'WordPress';
$pos = strpos($mystring, $findme);

if ($pos !== false) {
	echo "The string has been found";
} else {
	echo "String not found";
}

في المثال أعلاه ، استخدمنا !==عامل المقارنة ، والذي يتحقق مما إذا كانت قيمتان من نفس النوع. هذا يمنعنا من الحصول على خطأ إذا كان موضع الإبرة 0 :

“قد ترجع هذه الدالة Boolean FALSE ، ولكنها قد ترجع أيضًا قيمة غير منطقية يتم تقييمها إلى FALSE . […] استخدم عامل التشغيل === لاختبار قيمة الإرجاع لهذه الوظيفة. “

علاوة على ذلك ، توفر العديد من الأطر وظائف مساعدة للبحث عن قيمة داخل سلسلة معينة (انظر توثيق Laravel Helpers كمثال).

الآن، هذا RFC يقترح استحداث وظيفة جديدة تسمح للبحث داخل سلسلة: str_contains.

str_contains ( string $haystack , string $needle ) : bool

استخدامه واضح ومباشر. str_containsيتحقق مما إذا $needleتم العثور عليه $haystackوإرجاعه trueأو falseوفقًا لذلك.

لذلك ، بفضل str_contains، يمكننا كتابة الكود التالي:

$mystring = 'Managed WordPress Hosting';
$findme   = 'WordPress';

if (str_contains($mystring, $findme)) {
	echo "The string has been found";
} else {
	echo "String not found";
}

أيهما أكثر قابلية للقراءة وأقل عرضة للأخطاء (راجع هذا الرمز أثناء العمل هنا ).

في وقت كتابة هذه السطور ، كانت str_containsحساسة لحالة الأحرف ، لكن هذا قد يتغير في المستقبل.

تم str_containsتمرير الاقتراح بأغلبية 43 مقابل 9 أصوات.

str_starts_with () و str_ends_with ()

بالإضافة إلى str_containsالوظيفة ، تسمح وظيفتان جديدتان بالبحث عن إبرة داخل سلسلة معينة: str_starts_withو str_ends_with.

تتحقق هذه الوظائف الجديدة مما إذا كانت سلسلة معينة تبدأ أو تنتهي بسلسلة أخرى:

str_starts_with (string $haystack , string $needle) : bool
str_ends_with (string $haystack , string $needle) : bool

تعود كلتا الوظيفتين falseإذا كان $needleأطول من $haystack.

وفقًا لـ Will Hudgins ، مؤلف هذا RFC ،

“إن str_starts_withو str_ends_withيتم ذلك حاجة ظائف عادة أن العديد من الأطر PHP رئيسية تدعم ذلك، بما في ذلك في symfony ، لارافل ، Yii ، FuelPHP ، و فالكون “.

بفضلهم ، يمكننا الآن تجنب استخدام وظائف دون المستوى وأقل بديهية مثل substr، strpos. كلتا الوظيفتين حساسة لحالة الأحرف:

$str = "WordPress";
if (str_starts_with($str, "Word")) echo "Found!";

if (str_starts_with($str, "word")) echo "Not found!";

يمكنك رؤية هذا الرمز في العمل هنا .

تمت الموافقة على طلب التعليقات هذا بأغلبية 51 صوتًا مقابل 4 أصوات.

get_debug_type

get_debug_typeهي دالة PHP جديدة تُرجع نوع المتغير. تعمل الوظيفة الجديدة بطريقة مشابهة تمامًا gettypeللدالة ، ولكنها get_debug_typeتُرجع أسماء الأنواع الأصلية وتحل أسماء الفئات.

يعد هذا تحسينًا جيدًا للغة ، حيث gettype()لا يفيد في التحقق من الكتابة.

يقدم RFC مثالين مفيدين لفهم الفرق بين get_debug_type()الوظيفة الجديدة و gettype(). المثال الأول يظهر gettypeفي العمل:

$bar = [1,2,3];

$bar = [1,2,3];

if (!($bar instanceof Foo)) { 
	throw new TypeError('Expected ' . Foo::class . ', got ' . (is_object($bar) ? get_class($bar) : gettype($bar)));
}

باستخدام PHP 8 ، يمكننا استخدام get_debug_type:

if (!($bar instanceof Foo)) { 
	throw new TypeError('Expected ' . Foo::class . ' got ' . get_debug_type($bar));
}

يوضح الجدول التالي القيم المرجعة لـ get_debug_typeو gettype:

قيمة       gettype ()         get_debug_type ()

1          عدد صحيح          int

0.1        مزدوج    تطفو

حقيقية     قيمة منطقية          منطقي

خاطئة     قيمة منطقية          منطقي

باطل      باطل      باطل

“وورد بريس”       سلسلة     سلسلة

[1،2،3]  مجموعة مصفوفة   مجموعة مصفوفة

فئة تحمل الاسم “Foo \ Bar” موضوع  فو \ بار

فئة مجهولة           موضوع  class @ anonymous

طلبات التعليقات الإضافية

فيما يلي قائمة سريعة بالتحسينات الإضافية المعتمدة القادمة مع PHP 8:

واجهة Stringable : تقدم RFC واجهة Stringable تتم إضافتها تلقائيًا إلى الفئات التي تطبق __to String()الطريقة . الهدف الرئيسي هنا هو استخدام string|Stringableنوع الاتحاد.

واجهات برمجة التطبيقات الجديدة لـ DOM Living Standard في ext / dom : يقترح RFC هذا تنفيذ معيار المعيشة DOM الحالي إلى امتداد PHP DOM من خلال تقديم واجهات جديدة وخصائص عامة.

ثابت نوع الإرجاع : PHP 8 يدخل استخدام staticكنوع عودة بجانب selfو parentأنواع.

تعديلات بناء الجملة المتغيرة : RFC هذا يحل بعض التناقضات المتبقية في بناء الجملة المتغير لـ PHP.

معايير أداء PHP 8

إذا كنت تتساءل عن مدى سرعة PHP 8 ، فلدينا الإجابة. قمنا بقياس 20 منصة / تكوين PHP على 7 إصدارات PHP مختلفة (5.6 و 7.0 و 7.1 و 7.2 و 7.3 و 8.0).

برز PHP 8.0 باعتباره الفائز في معظم الأنظمة الأساسية التي تدعمه ، بما في ذلك وورد بريس و Laravel.

تم تجميع معايير PHP لأفضل المنصات

تم تجميع معايير PHP لأفضل المنصات

على سبيل المثال ، يمكن لـ وورد بريس على PHP 8.0 معالجة طلبات أكثر بنسبة 18.4٪ في الثانية مقارنة بـ PHP 7.4. وبالمثل ، فإن Laravel على PHP 8.0 يمكنه تشغيل طلبات أكثر بنسبة 8.5٪ في الثانية من PHP 7.3.

إذا كان موقع الويب أو التطبيق الخاص بك متوافقًا تمامًا مع PHP 8.0 ، فيجب أن تخطط لتحديث بيئة الخادم الخاص بك إلى PHP 8.0 في أقرب وقت ممكن. ستقدر أنت (ومستخدميك) بالتأكيد فوائد الأداء. ومع ذلك ، يرجى اختبار موقعك بدقة قبل التحديث.

يمكنك قراءة مقال معايير PHP للحصول على مزيد من المعلومات ، مثل بيانات الأداء التفصيلية والرؤى والرسوم البيانية الجميلة!

تم إصدار PHP 8 إلى GA ويقدم الكثير من التحسينات والميزات للغة. 🚀 تحقق من الغوص العميق في PHP 8!

انقر للتغريد

ملخص

ما مطية! في هذا المنشور ، قمنا بتغطية التحسينات والميزات الأكثر إثارة للاهتمام التي تأتي مع PHP 8. وأكثرها انتظارًا بالتأكيد هو مترجم Just in Time ، ولكن هناك الكثير مع PHP 8.

تأكد من وضع إشارة مرجعية على منشور المدونة هذا للرجوع إليه في المستقبل. 🤓

حان دورك الآن: هل أنت مستعد لاختبار ميزات PHP الجديدة؟ أي واحد هو المفضل لديك؟ إسقاط سطر في قسم التعليقات أدناه.

وفر الوقت والتكاليف وحقق أقصى قدر من أداء الموقع من خلال:

مساعدة فورية من خبراء استضافة وورد بريس ، 24/7.

تكامل Cloudflare Enterprise.

يصل الجمهور العالمي إلى 28 مركز بيانات حول العالم.

التحسين من خلال مراقبة أداء التطبيقات المضمنة لدينا.