تختبر JetBrains في Kotlin 2.5.0 آليتين جديدتين باسم Companion Blocks وCompanion Extensions، بهدف توسيع طريقة تعريف الأعضاء المرتبطة بالنوع وتحسين قابلية التشغيل البيني بين منصات Kotlin المختلفة. وتقول الشركة إن التصميم الجديد يفتح أنماطاً برمجية لم تكن متاحة بسهولة باستخدام Companion Objects التقليدية.
ما الذي تضيفه الآلية الجديدة؟
تُستخدم الأعضاء المرتبطة بالنوع لتعريف الثوابت والأدوات ودوال الإنشاء التي لا تنتمي إلى كائن منفرد، مثل ثابت يمثل المتجه الصفري أو دالة تنشئ متجهاً وفق زاوية محددة. في السابق كان هذا الاستخدام يعتمد على Companion Objects، بينما تتيح كتل المرافق الجديدة كتابة هذا النوع من الأعضاء بصياغة أقرب إلى تعريفها داخل النوع نفسه.
أما Companion Extensions فتسمح بإضافة أعضاء مرتبطة إلى أي فئة أو واجهة، حتى عندما لا يكون المطور مالكاً للكود الأصلي، وحتى إذا كان النوع آتياً من Java أو لا يحتوي أصلاً على Companion Object. ويعني ذلك إمكانية توسيع أنواع خارجية دون تعديل تعريفها الأساسي.
تغييرات في الترجمة والتوافق
تختلف الآلية الجديدة عن Companion Objects في استراتيجية الترجمة. فعلى منصة JVM، تُترجم Companion Blocks إلى أعضاء static، وهو ما يقرب سلوكها من الأعضاء الساكنة في منصات أخرى. وترى JetBrains أن ذلك قد يفيد Kotlin Multiplatform، إذ يمكن تعريف أعضاء متوقعة في كتلة مرافق ثم تحقيقها باستخدام فئة Java تحتوي على أعضاء static.
لكن الميزات ما زالت تجريبية. يتطلب تفعيل Companion Blocks استخدام الخيار -Xcompanion-blocks، بينما يتطلب الجمع بين الكتل والامتدادات الخيار -Xcompanion-blocks-and-extensions.
قيود الاستخدام التجريبي
عند استخدام Companion Extensions، ينتج المترجم ملفات ثنائية ما قبل الإصدار. وبناءً عليه، قد لا تتمكن المشاريع أو المكتبات الأخرى من استهلاك مكتبات تستخدم هذه الامتدادات بوصفها تبعيات إلى أن تستقر الميزة رسمياً. ولا ينطبق القيد نفسه على كشف Companion Blocks، لكن مستخدميها سيحتاجون أيضاً إلى تفعيل الميزة.
هل يجب ترحيل Companion Objects؟
لا توصي JetBrains بترحيل فوري. فـ Companion Objects ما تزال جزءاً أساسياً من Kotlin، والدعم الكامل لها مضمون. وقد تكون Companion Blocks الخيار المفضل للكود الجديد في معظم الحالات، لكن Companion Objects تظل ضرورية في حالات معينة، مثل حاجة المرافق إلى تطبيق واجهة، لأنها تُترجم إلى فئة كاملة.
عملياً، قد يكفي في كثير من الحالات حذف الكلمة object للانتقال إلى Companion Block، لكن المشروع وكل كود يعتمد عليه سيحتاجان إلى إعادة الترجمة. كما تحذر JetBrains من أن بعض أدوات المنظومة قد لا تكون جاهزة بعد للتعامل مع الصياغة الجديدة.
لماذا يهم هذا التطور؟
التغيير مهم لمطوري Kotlin Multiplatform ولمؤلفي المكتبات، لأنه يحاول تقليل الفجوة بين مفهوم الأعضاء الساكنة في JVM والمنصات الأخرى. غير أن قيمته العملية حالياً تظل مرتبطة بمرحلة تجريبية وبمدى سرعة تحديث أدوات البناء والمكتبات والمحررات. لذلك تبدو Companion Blocks مناسبة للتجربة وتقييم التصميم، لا كأساس آمن لترحيل واسع قبل استقرار الميزة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.