ما الجديد في PHP 8.2 - الميزات الجديدة ، والاستنكارات ، والتغييرات ، والمزيد

يعتمد PHP 8.2 على القاعدة المتجددة المنصوص عليها في PHP 8.0 و PHP 8.1. من المخطط إطلاقه في 24 نوفمبر 2022.

ستغطي هذه المقالة الجديد في PHP 8.2 بالتفصيل - بدءًا من الميزات والتحسينات الجديدة إلى الإهمالات والتغييرات الطفيفة ، سنتناولها جميعًا.

مع دخول PHP 8.2 إلى تجميد الميزات في 19 يوليو 2022 ، لا يمكنك توقع أي إضافات مهمة إلى هذه القائمة.

فرح؟ كانت أيضا.

هيا نبدأ!

الميزات والتحسينات الجديدة في PHP 8.2

لنبدأ باستكشاف أحدث ميزات PHP 8.2. إنها قائمة واسعة جدًا:

فصول جديدة readonly

قدم PHP 8.1 ميزة readonly لخصائص الفئة. الآن ، PHP 8.2 تضيف دعمًا للإعلان أن الفصل بأكمله readonly .

إذا أعلنت أن فئة ما readonly ، فسوف ترث جميع خصائصها تلقائيًا ميزة readonly . وبالتالي ، فإن إعلان فئة ما readonly هو نفس إعلان كل خاصية فئة على أنها readonly .

على سبيل المثال ، مع PHP 8.1 ، كان عليك كتابة هذا الرمز الشاق للإعلان عن جميع خصائص الفئة على أنها readonly :

 class MyClass { public readonly string $myValue, public readonly int $myOtherValue public readonly string $myAnotherValue public readonly int $myYetAnotherValue }

تخيل نفس الشيء مع العديد من الخصائص. الآن ، مع PHP 8.2 ، يمكنك فقط كتابة ما يلي:

 readonly class MyClass { public string $myValue, public int $myOtherValue public string $myAnotherValue public int $myYetAnotherValue }

يمكنك أيضًا إعلان أن الفصول المجردة أو النهائية readonly . هنا ، لا يهم ترتيب الكلمات الرئيسية.

 abstract readonly class Free {} final readonly class Dom {}

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

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

يمكنك استخدام خاصية النوع mixed إذا لم تتمكن من إعلان خاصية مكتوبة بدقة.

ستؤدي محاولة التصريح عن فئة readonly بدون خاصية مكتوبة إلى حدوث خطأ فادح:

 readonly class Type { public $nope; } Fatal error: Readonly property Type::$nope must have type in ... on line ...

علاوة على ذلك ، لا يمكنك التصريح readonly لبعض ميزات PHP:

• Enums (حيث لا يمكن أن تحتوي على أي خاصية)
• سمات
• واجهات

ستؤدي محاولة إعلان أي من هذه الميزات على أنها readonly إلى حدوث خطأ في التحليل.

 readonly interface Destiny {} Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...

كما هو الحال بالنسبة لجميع الكلمات الرئيسية في PHP ، فإن الكلمة الأساسية readonly غير حساسة لحالة الأحرف.

تقوم PHP 8.2 أيضًا بإهمال الخصائص الديناميكية (المزيد حول ذلك لاحقًا). لكن لا يمكنك منع إضافة الخصائص الديناميكية إلى فئة. ومع ذلك ، فإن القيام بذلك لفصل readonly سيؤدي فقط إلى حدوث خطأ فادح.

 Fatal error: Readonly property Test::$test must have type in ... on line ...

السماح true false null كأنواع مستقلة

تتضمن PHP بالفعل أنواعًا عددية مثل int و string و bool . تم توسيع ذلك في PHP 8.0 مع إضافة أنواع الاتحاد ، مما يسمح للقيم بأن تكون من أنواع مختلفة. كما سمح RFC نفسه باستخدام false و null كجزء من نوع الاتحاد - لم يكن مسموحًا بهما كأنواع قائمة بذاتها ، على الرغم من ذلك.

إذا حاولت الإعلان عن false أو null أو كأنواع قائمة بذاتها - دون أن تكون جزءًا من نوع اتحاد - فقد نتج عن ذلك خطأ فادح.

 function spam(): null {} function eggs(): false {} Fatal error: Null can not be used as a standalone type in ... on line ... Fatal error: False can not be used as a standalone type in ... on line ...

لتجنب هذا السيناريو ، تضيف PHP 8.2 دعمًا لاستخدام false و null كأنواع قائمة بذاتها. مع هذه الإضافة ، يصبح نظام الكتابة في PHP أكثر تعبيرًا واكتمالًا. يمكنك الآن التصريح عن أنواع الإرجاع والمعلمة وأنواع الخصائص بدقة.

أيضًا ، لا تزال PHP لا تتضمن نوعًا true ، والذي يبدو أنه نظير طبيعي للنوع false . يصلح PHP 8.2 ذلك ويضيف دعمًا للنوع true أيضًا. لا يسمح بالإكراه ، تمامًا مثل سلوك النوع false .

كلا النوعين true false هما في الأساس نوع اتحاد لنوع PHP bool . لتجنب التكرار ، لا يمكنك التصريح عن هذه الأنواع الثلاثة معًا في نوع اتحاد. سيؤدي القيام بذلك إلى خطأ فادح في وقت الترجمة.

أنواع النموذج العادي المنفصل (DNF)

النموذج العادي المنفصل (DNF) هو طريقة معيارية لتنظيم التعبيرات المنطقية. وهو يتألف من فصل الاقترانات - بالمصطلحات المنطقية ، هذا هو OR لـ AND .

يتيح تطبيق DNF على تعريفات الكتابة طريقة قياسية لكتابة أنواع الاتحاد والتقاطع المدمجة التي يمكن للمحلل التعامل معها. تعد ميزة أنواع DNF الجديدة في PHP 8.2 بسيطة لكنها قوية إذا تم استخدامها بشكل صحيح.

يعطي RFC المثال التالي. يفترض أن تعريفات الفئة والواجهة التالية موجودة بالفعل:

 interface A {} interface B {} interface C extends A {} interface D {} class W implements A {} class X implements B {} class Y implements A, B {} class Z extends Y implements C {}

باستخدام أنواع DNF ، يمكنك تنفيذ إعلانات الأنواع للخصائص والمعلمات والقيم المرجعة مثل:

 // Accepts an object that implements both A and B, // OR an object that implements D (A&B)|D // Accepts an object that implements C, // OR a child of X that also implements D, // OR null C|(X&D)|null // Accepts an object that implements all three of A, B, and D, // OR an int, // OR null. (A&B&D)|int|null

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

 A&(B|D) // Can be rewritten as (A&B)|(A&D) A|(B&(D|W)|null) // Can be rewritten as A|(B&D)|(B&W)|null

يجب أن تلاحظ أن كل جزء من نوع DNF يجب أن يكون فريدًا. على سبيل المثال ، التصريح (A&B)|(B&A) غير صالح لأن مقطعي OR متماثلان منطقيًا.

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

معلمات الحساسية في آثار الظهر

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

لا يؤدي إجراء تتبع المكدس إلى إيقاف تنفيذ البرنامج. عادةً ما تعمل معظم تتبعات المكدس في الخلفية ويتم تسجيلها بصمت - لفحصها لاحقًا إذا لزم الأمر.

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

يقدم اقتراح RFC هذا أحد الأمثلة:

أحد "المخالفين" الشائعين هو PDO الذي يأخذ كلمة مرور قاعدة البيانات كمعامل مُنشئ ويحاول على الفور الاتصال بقاعدة البيانات داخل المُنشئ ، بدلاً من وجود مُنشئ خالص وطريقة منفصلة -> connect () . وبالتالي عندما يفشل اتصال قاعدة البيانات ، سيتضمن تتبع المكدس كلمة مرور قاعدة البيانات:

 PDOException: SQLSTATE[HY000] [2002] No such file or directory in /var/www/html/test.php:3 Stack trace: #0 /var/www/html/test.php(3): PDO->__construct('mysql:host=loca...', 'root', 'password') #1 {main}

يسمح لك PHP 8.2 بتمييز هذه المعلمات الحساسة \SensitiveParameter جديدة. لن يتم سرد أي معلمة تم تمييزها بأنها حساسة في مسارات الخلفية الخاصة بك. وبالتالي ، يمكنك مشاركتها دون مخاوف مع أي خدمات طرف ثالث.

إليك مثال مباشر بمعامل واحد حساس:

 <?php function example( $ham, #[\SensitiveParameter] $eggs, $butter ) { throw new \Exception('Error'); } example('ham', 'eggs', 'butter'); /* Fatal error: Uncaught Exception: Error in test.php:8 Stack trace: #0 test.php(11): test('ham', Object(SensitiveParameterValue), 'butter') #1 {main} thrown in test.php on line 8 */

عند إنشاء تتبع رجعي ، سيتم استبدال أي معلمة \SensitiveParameter \SensitiveParameterValue بكائن \ SensitiveParameterValue ، ولن يتم تخزين قيمتها الحقيقية في التتبع. يقوم كائن SensitiveParameterValue بتغليف قيمة المعلمة الفعلية - إذا كنت بحاجة إليها لأي سبب.

دالة mysqli_execute_query الجديدة وطريقة mysqli::execute_query

هل سبق لك استخدام الدالة mysqli_query() مع الهروب الخطير من قيم المستخدم فقط لتشغيل استعلام MySQLi ذي معلمات؟

يجعل PHP 8.2 تشغيل استعلامات MySQLi ذات المعلمات أسهل باستخدام mysqli_execute_query($sql, $params) وطريقة mysqli::execute_query .

بشكل أساسي ، هذه الوظيفة الجديدة هي مزيج من mysqli_prepare() و mysqli_execute() و mysqli_stmt_get_result() . باستخدامه ، سيتم إعداد استعلام MySQLi وربطه (إذا مررت أي معلمات) وتنفيذها داخل الوظيفة نفسها. إذا تم تشغيل الاستعلام بنجاح ، فسيعيد كائن mysqli_result . إذا لم تنجح ، فستعود false .

يقدم اقتراح RFC مثالًا بسيطًا ولكنه قوي:

 foreach ($db->execute_query('SELECT * FROM user WHERE name LIKE ? AND type_id IN (?, ?)', [$name, $type1, $type2]) as $row) { print_r($row); }

إحضار خصائص enum في تعبيرات const

يقترح RFC السماح للعامل ->/?-> بجلب خصائص enum في تعبيرات const .

السبب الرئيسي لهذه الميزة الجديدة هو أنه لا يمكنك استخدام كائنات enum في بعض الأماكن ، مثل مفاتيح الصفيف. في مثل هذه الحالة ، سيتعين عليك تكرار قيمة حالة enum لمجرد استخدامها.

يمكن أن يؤدي السماح بجلب خصائص enum في الأماكن التي لا يُسمح فيها بكائنات enum إلى تبسيط هذا الإجراء.

هذا يعني أن الكود التالي صالح الآن:

 const C = [self::B->value => self::B];

ولكي تكون آمنًا ، يتضمن RFC هذا أيضًا دعمًا لمشغل nullsafe ?-> .

السماح بالثوابت في السمات

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

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

يقترح RFC هذا للسماح بتعريف الثوابت في السمات. يمكن تعريف هذه الثوابت تمامًا كما تحدد ثوابت الفئة. هذا المثال المأخوذ مباشرة من RFC يزيل الهواء المحيط باستخدامه:

 trait Foo { public const FLAG_1 = 1; protected const FLAG_2 = 2; private const FLAG_3 = 2; public function doFoo(int $flags): void { if ($flags & self::FLAG_1) { echo 'Got flag 1'; } if ($flags & self::FLAG_2) { echo 'Got flag 2'; } if ($flags & self::FLAG_3) { echo 'Got flag 3'; } } }

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

الإيقاف في PHP 8.2

يمكننا الآن الانتقال لاستكشاف جميع الإهمالات في PHP 8.2. هذه القائمة ليست كبيرة مثل ميزاتها الجديدة:

تجاهل الخصائص الديناميكية (والسمة الجديدة #[AllowDynamicProperties] )

حتى إصدار PHP 8.1 ، يمكنك تعيين واسترداد خصائص الفئة غير المعلنة ديناميكيًا في PHP. فمثلا:

 class Post { private int $pid; } $post = new Post(); $post->name = 'Kinsta';

هنا ، لا تعلن فئة Post عن خاصية name . ولكن نظرًا لأن PHP تسمح بالخصائص الديناميكية ، يمكنك تعيينها خارج إعلان الفئة. هذه هي الميزة الأكبر - وربما الوحيدة -.

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

من PHP 8.2 وما بعده ، تم إهمال الخصائص الديناميكية. سيؤدي تعيين قيمة لخاصية فئة غير معرّفة إلى إرسال إشعار إهمال في المرة الأولى التي يتم فيها تعيين الخاصية.

 class Foo {} $foo = new Foo; // Deprecated: Creation of dynamic property Foo::$bar is deprecated $foo->bar = 1; // No deprecation warning: Dynamic property already exists. $foo->bar = 2;

ومع ذلك ، بدءًا من PHP 9.0 وما بعده ، سيؤدي تعيين نفس الإعداد إلى ظهور خطأ ErrorException .

إذا كانت شفرتك مليئة بالخصائص الديناميكية - وهناك الكثير من أكواد PHP - وإذا كنت تريد إيقاف إشعارات الإيقاف هذه بعد الترقية إلى PHP 8.2 ، فيمكنك استخدام سمة #[AllowDynamicProperties] الجديدة في PHP 8.2 للسماح بالديناميكية خصائص في الفصول الدراسية.

 #[AllowDynamicProperties] class Pets {} class Cats extends Pets {} // You'll get no deprecation warning $obj = new Pets; $obj->test = 1; // You'll get no deprecation warning for child classes $obj = new Cats; $obj->test = 1;

وفقًا لـ RFC ، يمكن للفئات المميزة بعلامة #[AllowDynamicProperties] ، بالإضافة إلى الفئات الفرعية ، الاستمرار في استخدام الخصائص الديناميكية دون إهمال أو إزالة.

يجب أن تلاحظ أيضًا أنه في PHP 8.2 ، الفئة المجمعة الوحيدة التي تم وضع علامة عليها كـ #[AllowDynamicProperties] هي stdClass . علاوة على ذلك ، فإن أي خصائص يتم الوصول إليها من خلال __get() أو __set() PHP magic لا تُعتبر خصائص ديناميكية ، لذلك لن يتم إصدار إشعار بالإيقاف.

تجاهل العناصر القابلة للاستدعاء المدعومة جزئيًا

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

يُطلق على هذه العناصر القابلة للاستدعاء "مدعومة جزئيًا" لأنه لا يمكنك التفاعل معها مباشرةً عبر $callable() . يمكنك فقط الوصول إليهم من خلال call_user_func($callable) . قائمة هذه العناصر القابلة للاستدعاء ليست طويلة:

 "self::method" "parent::method" "static::method" ["self", "method"] ["parent", "method"] ["static", "method"] ["Foo", "Bar::method"] [new Foo, "Bar::method"]

بدءًا من PHP 8.2 وما بعده ، ستؤدي أي محاولات لاستدعاء مثل هذه العناصر القابلة للاستدعاء - مثل عبر call_user_func() أو array_map() - إلى إطلاق تحذير من الإهمال.

يعطي RFC الأصلي سببًا قويًا وراء هذا الإهمال:

بصرف النظر عن الحالتين الأخيرتين ، فإن كل هذه العناصر القابلة للاستدعاء تعتمد على السياق. تعتمد الطريقة التي تشير إليها "self::method" على الفئة التي يتم إجراء فحص الاستدعاء أو إمكانية الاستدعاء منها. من الناحية العملية ، ينطبق هذا أيضًا على الحالتين الأخيرتين ، عند استخدامه في شكل [new Foo, "parent::method"] .

الحد من الاعتماد على سياق العناصر القابلة للاستدعاء هو الهدف الثانوي لهذا RFC. بعد طلب التعليقات هذا ، لا يزال الاعتماد على النطاق الوحيد هو رؤية الطريقة: قد يكون "Foo::bar" مرئيًا في نطاق واحد ، ولكن ليس في نطاق آخر. إذا كانت العناصر القابلة للاستدعاء ستقتصر على الطرق العامة في المستقبل (بينما يجب أن تستخدم الأساليب الخاصة كوابل من الدرجة الأولى أو Closure::fromCallable() لتصبح مستقلة عن النطاق) ، فإن النوع القابل للاستدعاء سيصبح محددًا جيدًا ويمكن أن يمكن استخدامه كنوع خاصية. ومع ذلك ، لا يُقترح إجراء تغييرات على معالجة الرؤية كجزء من طلب التعليقات هذا .

وفقًا لـ RFC الأصلي ، ستستمر وظيفة is_callable() callable في قبول هذه العناصر القابلة للاستدعاء كاستثناءات. ولكن فقط حتى يتم إزالة الدعم الخاص بهم تمامًا من PHP 9.0 فصاعدًا.

لتجنب الارتباك ، تم توسيع نطاق إشعار الإيقاف هذا باستخدام RFC جديد - وهو يتضمن الآن هذه الاستثناءات.

من الجيد أن ترى PHP تتجه نحو الحصول على نوع callable محدد جيدًا.

#utf8_encode() و utf8_decode()

تعمل الدالات المدمجة في PHP مثل utf8_encode() و utf8_decode() تحويل السلاسل المشفرة في ISO-8859-1 ("اللاتينية 1") من وإلى UTF-8.

ومع ذلك ، فإن أسمائهم تشير إلى استخدام أكثر عمومية مما يسمح به تنفيذها. عادةً ما يتم الخلط بين الترميز "Latin 1" والتشفير الآخر مثل "Windows Code Page 1252."

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

PHP 8.2 يبطل كلاً من #utf8_encode() و utf8_decode() . إذا قمت باستدعائهم ، فسترى إشعارات الإيقاف هذه:

 Deprecated: Function utf8_encode() is deprecated Deprecated: Function utf8_decode() is deprecated

يقترح RFC استخدام ملحقات PHP المدعومة مثل mbstring و iconv و intl بدلاً من ذلك.

إيقاف ${} String Interpolation

تسمح PHP بتضمين المتغيرات في سلاسل ذات علامات اقتباس مزدوجة ( " ) و ( <<< ) بعدة طرق:

1. تضمين المتغيرات مباشرةً - “$foo”
2. بأقواس خارج المتغير - “{$foo}”
3. بأقواس بعد علامة الدولار - “${foo}”
4. المتغيرات المتغيرة - “${expr}” - تعادل استخدام (string) ${expr}

الطريقتان الأوليان لهما إيجابيات وسلبيات ، في حين أن الطريقتين الأخيرتين لهما بناء جملة معقد ومتضارب. PHP 8.2 يبطل الطريقتين الأخيرتين لاستيفاء السلسلة.

يجب أن تبتعد عن استيفاء السلاسل بهذه الطريقة للمضي قدمًا:

 "Hello, ${world}!"; Deprecated: Using ${} in strings is deprecated "Hello, ${(world)}!"; Deprecated: Using ${} (variable variables) in strings is deprecated

بدءًا من PHP 9.0 ، ستتم ترقية عمليات الإهمال هذه لإلقاء خطأ استثناء.

إيقاف وظائف mbstring لكيانات Base64 / QPrint / Uuencode / HTML

تساعدنا وظائف mbstring (سلسلة متعددة البايت) في PHP على العمل مع كيانات Unicode و HTML وغيرها من ترميزات النصوص القديمة.

ومع ذلك ، فإن Base64 و Uuencode و QPrint ليست ترميزات نصية ولا تزال جزءًا من هذه الوظائف - ويرجع ذلك أساسًا إلى أسباب قديمة. تتضمن PHP أيضًا تطبيقات منفصلة لهذه الترميزات.

بالنسبة إلى كيانات HTML ، تحتوي PHP على وظائف مضمنة - htmlspecialchars() و htmlentities ( htmlentities() - للتعامل معها بشكل أفضل. على سبيل المثال ، على عكس mbstring ، فإن هذه الدوال ستحول أيضًا < . > ، والرموز & إلى كيانات HTML.

علاوة على ذلك ، تعمل PHP دائمًا على تحسين وظائفها المضمنة - تمامًا مثل PHP 8.1 مع وظائف تشفير وفك تشفير HTML.

لذلك ، مع أخذ كل ذلك في الاعتبار ، فإن PHP 8.2 تتجاهل استخدام mbstring لهذه الترميزات (التسميات غير حساسة لحالة الأحرف):

• BASE64
• UUENCODE
• كيانات HTML
• html (الاسم المستعار لـ HTML-ENTITIES)
• ونقلت للطباعة
• qprint (الاسم المستعار لـ Quoted-Printable)

بدءًا من PHP 8.2 وما بعده ، فإن استخدام mbstring لتشفير / فك ترميز أي مما سبق سيصدر إشعارًا بالإيقاف. سيقوم PHP 9.0 بإزالة دعم mbstring لهذه الترميزات تمامًا.

تغييرات طفيفة أخرى في PHP 8.2

أخيرًا ، يمكننا مناقشة التغييرات الطفيفة في PHP 8.2 ، بما في ذلك الميزات والوظائف التي تمت إزالتها.

إزالة دعم libmysql من mysqli

اعتبارًا من الآن ، تسمح PHP لكل من برامج تشغيل mysqli و PDO_mysql بالبناء على مكتبات mysqlnd و libmysql . ومع ذلك ، فإن برنامج التشغيل الافتراضي والموصى به منذ PHP 5.4 كان mysqlnd .

كلا هذين السائقين لهما العديد من المزايا والعيوب. ومع ذلك ، فإن إزالة الدعم لأحدها - من الناحية المثالية ، إزالة libmysql لأنه ليس الإعداد الافتراضي - سوف يبسط كود PHP واختبارات الوحدة.

لتقديم حجة لهذه الخدمة ، يسرد RFC العديد من مزايا mysqlnd :

• إنها مجمعة مع PHP
• يستخدم إدارة ذاكرة PHP لمراقبة استخدام الذاكرة وملفات
  تحسين الأداء
• يوفر وظائف جودة الحياة (مثل get_result() )
• إرجاع القيم الرقمية باستخدام أنواع PHP الأصلية
• لا تعتمد وظيفتها على المكتبة الخارجية
• وظيفة البرنامج المساعد الاختيارية
• يدعم الاستعلامات غير المتزامنة

يسرد RFC أيضًا بعض مزايا libmysql ، بما في ذلك:

• إعادة الاتصال التلقائي ممكنة (لا تدعم mysqlnd هذه الوظيفة عن قصد لأنه يمكن استغلالها بسهولة)
• أوضاع مصادقة LDAP و SASL (قد تضيف mysqlnd هذه الميزة قريبًا أيضًا)

بالإضافة إلى ذلك ، يسرد RFC العديد من عيوب libmysql - عدم التوافق مع نموذج ذاكرة PHP ، والعديد من الاختبارات الفاشلة ، وتسرب الذاكرة ، والوظائف المختلفة بين الإصدارات ، وما إلى ذلك.

مع أخذ كل هذا في الاعتبار ، أزال PHP 8.2 الدعم لبناء mysqli ضد libmysql .

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

لغة مستقلة تحويل الحالة

قبل إصدار PHP 8.0 ، تم توريث لغة PHP من بيئة النظام. لكن هذا قد يسبب مشكلة في بعض الحالات الحادة.

سيؤدي تعيين لغتك أثناء تثبيت Linux إلى تعيين لغة واجهة المستخدم المناسبة للأوامر المضمنة فيها. ومع ذلك ، فإنه يغير أيضًا بشكل غير متوقع كيفية عمل وظيفة معالجة سلسلة مكتبة C.

على سبيل المثال ، إذا حددت اللغة "التركية" أو "الكازاخستانية" عند تثبيت Linux ، فستجد أن استدعاء toupper('i') للحصول على مكافئها بالأحرف الكبيرة سيحصل على الحرف الكبير المنقط I (U + 0130، I ).

أوقف PHP 8.0 هذه الحالة الشاذة عن طريق تعيين اللغة الافتراضية على "C" ، ما لم يغيرها المستخدم صراحةً عبر setlocale() .

يذهب PHP 8.2 إلى أبعد من ذلك عن طريق إزالة حساسية اللغة من تحويلات الحالة. يغير RFC هذا بشكل أساسي strtolower() و strtoupper() والوظائف ذات الصلة. اقرأ RFC للحصول على قائمة بجميع الوظائف المتأثرة.

كبديل ، إذا كنت تريد استخدام تحويل الحالة المترجمة ، فيمكنك استخدام mb_strtolower() .

تحسين الامتداد العشوائي

تخطط PHP لإصلاح وظائفها العشوائية.

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

يمكن أن يكون الحفاظ على مثل هذا الرمز أكثر تعقيدًا عندما تستخدم التعليمات البرمجية حزمًا خارجية.

وبالتالي ، لا يمكن للوظيفة العشوائية الحالية لـ PHP إعادة إنتاج القيم العشوائية بشكل متسق. حتى أنه فشل في الاختبارات الإحصائية التجريبية لمولدات الأرقام العشوائية الموحدة ، مثل Crush و BigCrush TestU01. يؤدي تقييد Mersenne Twister البالغ 32 بت إلى تفاقم ذلك.

وبالتالي ، فإن استخدام الدوال المضمنة في PHP - shuffle() و str_shuffle() و array_rand() - غير مستحسن إذا كنت بحاجة إلى أرقام عشوائية آمنة مشفرة. في مثل هذه الحالات ، ستحتاج إلى تنفيذ وظيفة جديدة باستخدام random_int() أو وظائف مماثلة.

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

RFCs إضافية في PHP 8.2

يتضمن PHP 8.2 أيضًا العديد من الوظائف الجديدة والتغييرات الطفيفة. سنذكرها أدناه مع روابط لموارد إضافية:

1. وظيفة curl_upkeep الجديدة: يضيف PHP 8.2 هذه الوظيفة الجديدة إلى امتداد Curl الخاص بها. يستدعي الدالة curl_easy_upkeep() في libcurl ، مكتبة C الأساسية التي يستخدمها امتداد PHP Curl.
2. دالة ini_parse_quantity جديدة: تقبل توجيهات PHP INI أحجام البيانات مع لاحقة مضاعف. على سبيل المثال ، يمكنك كتابة 25 ميغا على شكل 25 25M أو 42 جيغابايت على شكل 42 42G فقط. هذه اللواحق شائعة في ملفات PHP INI ولكنها غير شائعة في أماكن أخرى. تقوم هذه الوظيفة الجديدة بتوزيع قيم PHP INI وإرجاع حجم بياناتها بالبايت.
3. وظيفة memory_reset_peak_usage الجديدة: تعيد هذه الوظيفة ضبط ذروة استخدام الذاكرة التي ترجعها وظيفة memory_get_peak_usage . يمكن أن يكون مفيدًا عندما تقوم بتشغيل نفس الإجراء عدة مرات وتريد تسجيل ذروة استخدام الذاكرة لكل تشغيل.
4. دعم معدل عدم الالتقاط ( /n ) في وظائف preg_* : في التعبير العادي ، تشير الأحرف الأولية () إلى مجموعة الالتقاط. هذا يعني أنه يتم إرجاع جميع المطابقات للتعبير داخل القوس. يضيف PHP 8.2 معدّل no-capture ( /n ) لإيقاف هذا السلوك.
5. اجعل عائلة iterator_*() تقبل جميع العناصر التكرارية: اعتبارًا من الآن ، تقبل عائلة iterator_*() \Traversables فقط (أي لا يُسمح بالمصفوفات العادية). إنه مقيد بشكل غير ضروري ، وهذا RFC يعمل على إصلاح ذلك.

ملخص

يعتمد PHP 8.2 على التحسينات الهائلة في PHP 8.0 و PHP 8.1 ، وهو ليس بالأمر السهل. نعتقد أن أكثر ميزات PHP 8.2 إثارة هي أنواعها المستقلة الجديدة وخصائصها للقراءة فقط والعديد من تحسينات الأداء.

لا يمكننا الانتظار لاختبار PHP 8.2 مع العديد من أطر عمل PHP وأنظمة إدارة المحتوى.

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

ما هي ميزات PHP 8.2 المفضلة لديك؟ ما هي الإهمالات الأقل تفضيلاً لديك؟ يرجى مشاركة أفكارك مع مجتمعنا في التعليقات!