في المستقبل القريب ، ستظهر ميزات جديدة بلغة Java ، والتي يتم العمل عليها حاليًا في إطار مشاريع Valhalla و Panama و Loom. إن توسيع لغة ما ليس بالمهمة السهلة ، لا سيما اللغة التي ينصب عليها التركيز على التوافق مع الإصدارات السابقة ؛ لذلك ، حتى يتم دمجها في Java بسلاسة ، يتعين على مهندسي اللغة حل المشكلات الأساسية المتراكمة.
بالأمس (8 يناير) ، نشر براين غوتز ، الذي يعمل لدى Oracle كمهندس لغة Java ،
خطابًا "نحتاج إلى المزيد من الكلمات الرئيسية ، Captain!" إلى القائمة البريدية للمشروع Amber
. حيث اقترح طريقة لحل مشكلة إضافة كلمات رئيسية جديدة إلى اللغة. نتيجةً لذلك ، قد تظهر الكلمات الرئيسية بلغة مثل
غير الفارغة وغير النهائية والنهائية وفي
النهاية هذه الإرجاع (هناك قائمة كاملة في انتظارك في نهاية الفصل في نهاية المنشور).
نظرًا لأن هذه المشكلة نشأت في الماضي بشكل متكرر ، لم يفكروا كثيرًا في الأمر و "حاولوا النزول من العنق بأسرع وقت ممكن" ؛ بسبب أوجه القصور في النهج الحالية في المستقبل ، فإن تطبيقها سيكون مشكلة ، وفي هذا الصدد ، فقد تقرر العمل مقدما. الحل المقترح: حاول توسيع مجموعة الأشكال المعجمية التي يمكن استخدامها ككلمات رئيسية: اسمح للكلمات الرئيسية مفصولة بواحد ، والتي ستستخدم كلمة رئيسية واحدة (أو أكثر) أو معرّف محجوز.
ملاحظة مهمة: يشير براون إلى أن الكلمات الرئيسية الجديدة يتم توفيرها فقط كمثال توضيحي ، ويجب ألا تركز عليها. ومع ذلك ، فمن الواضح أن أمامنا عرض مدروس جيدًا حول كيفية تغيير بناء الجملة للغة في المستقبل - يشير المؤلف في الرسالة إلى أن هذه الفكرة ستساعد في إضافة العديد من تصميمات اللغة المفقودة إلى Java إلى Java.
الأساليب "القديمة"
كما تعلمون ، يوجد اليوم بلغة Java 50 كلمة رئيسية (
الكلمات الرئيسية ) ، ممنوع استخدامها كمعرفات للمتغيرات. ترد قائمة كاملة
في مواصفات لغة JLS في الفقرة 3.9 . لم تتغير هذه القائمة كثيرًا منذ الإصدار الأول من اللغة -
تمت إضافة
التأكيد فقط في الإصدار 4 ،
التعداد في 5 و
_ في 9. بالإضافة إلىهم ، هناك أيضًا "معرّفات محجوزة" -
حقيقية ،
خاطئة و
خالية - تتصرف بشكل مشابه للكلمات الرئيسية الطريق.
عندما يحتاج المطورون إلى إضافة كلمة رئيسية جديدة إلى اللغة ، يتعين عليهم اللجوء إلى إحدى الطرق التالية.
- النقل القسري للملكية: نأخذ الكلمات التي كانت معرفات سابقًا ونحولها إلى كلمات رئيسية (على سبيل المثال ، التأكيد ).
- التخلص: يبدأ استخدام كلمة رئيسية موجودة بطريقة لم يكن الغرض منها استخدامها مطلقًا (مثال على ذلك هو استخدام الافتراضي لقيم التعليقات التوضيحية أو الأساليب الافتراضية).
- الاستغناء عنها: ابحث عن طريقة لاستخدام بناء الجملة التي لا تتطلب كلمة رئيسية جديدة - على سبيل المثال ، استخدم واجهة للتعليقات التوضيحية بدلاً من التعليق التوضيحي - أو اترك الميزة بالكامل.
- إنشاء الرؤية: إنشاء وهم الكلمات الرئيسية الحساسة للسياق باستخدام الإنجازات اللغوية البطولية ( الكلمات الرئيسية المقيدة ، أسماء الأنواع المحجوزة ).
من حيث المبدأ ، يمكن عادةً تطبيق أي من هذه الطرق ، ولكن لكل منها عيوبها ، ومن الواضح أن هذه الطرق وحدها ليست كافية - بالنسبة للابتكارات المستقبلية ، سيكون من الضروري القضاء على عدم القدرة على توسيع بناء جملة اللغة بالكامل.
إضافة كلمات رئيسية جديدة
هناك الحجج التالية ضد "عادل" أخذ وإضافة كلمات جديدة.
- كلما كانت الكلمة الرئيسية المحددة أكثر ملاءمة وشهرة ، زاد ظهورها في التعليمات البرمجية المصدر للبرامج ، مما سيضيف عدم التوافق إلى اللغة (على سبيل المثال ، عندما تظهر الكلمة assert في Java SE 1.4 ، توقفت جميع أطر العمل عن العمل).
- سوف تختلف تكلفة التخلص من عدم توافق الكود هذا من قبل المطور اختلافًا كبيرًا من صغير (إعادة تسمية متغير محلي) إلى فادح (عندما يتم إبطال طريقة الواجهة أو النوع العام).
- الكلمات التي يرجح أن يستخدمها مطورو اللغة هي معرفات شائعة (على سبيل المثال ، القيمة أو var أو الطريقة ) ؛
- إذا اخترت الكلمات التي نادراً ما تستخدم في الكود المصدري والتي سيكون بها عدد أقل من الاصطدامات ، فسوف يتعين عليك استخدام تصميمات مثل عادةً _but_not_always_final ، والتي سيكون من المستحسن تجنبها في اللغة.
- ومع ذلك ، إذا كنت تلجأ إلى اختيار الكلمات النادرة الاستخدام ، فلن ينجح استخدام هذه الطريقة كثيرًا - فكسر التوافق ليس جيدًا ، ولا يوجد الكثير من المجموعات الناجحة.
إعادة استخدام الكلمات الرئيسية "القديمة"
حول استمرار "مجرد" العيش مع هذه الكلمات ، هناك اعتبارات.
- توجد سوابق إعادة استخدام الكلمات الرئيسية في سياقات مختلفة في العديد من لغات البرمجة (مثال من Java هو استخدام ( (ab) use ) final للتعيينات "غير قابلة للتغيير" و "غير محددة" و "غير القابلة للتوسيع").
- في بعض الأحيان يكون هذا النهج منطقيًا ويأتي في حد ذاته ، لكنه عادة لا يمثل أولوية.
- مع مرور الوقت ، تتوسع مجموعة المتطلبات لمجموعة من الكلمات الرئيسية ، ويمكن أن تصل إلى نقطة مضحكة - لا أحد يريد استخدام null final في الكود.
- إذا بدا لك هذا الأخير مبالغة ، فعليك أن تضع في اعتبارك أنه أثناء العمل على JEP 325 اقترحوا بجدية استخدام رمز التبديل الجديد لوصف رمز التبديل مع دلالات مختلفة - إذا تابعت على نفس المنوال ، بعد عشر سنوات يمكننا الوصول إلى مفتاح جديد
كيف تعيش بدون كلمات رئيسية جديدة؟ من الممكن التوقف تمامًا عن الانخراط في تطور اللغة ، كما اقترح البعض. لكن هذا ليس خطيرًا ولا يتناسب مع رأي الباقي ، نظرًا لأن هناك اهتمامًا جيدًا بالميزات الجديدة للغة من المطورين.
الكلمات الرئيسية للسياق
يبدو أن الكلمات الرئيسية السياقية التي يتم استخدامها لتوفير معنى محدد في الشفرة ، ولكنها ليست كلمات محجوزة (
تستخدم في C # ) للوهلة الأولى ، هي نفس "العصا السحرية" ، لكن برايان يعرض رؤيته الخاصة بشأن استخدامها ، استنادًا إلى الممارسة ( على سبيل المثال ، تطبيقات
var في Java 10 ، وهي ليست كلمة أساسية ، ولكن
اسم نوع محجوز ). في مقابل الوهم بإضافة كلمات رئيسية جديدة دون الحاجة إلى "كسر" البرامج الحالية ، نحصل على زيادة التعقيد والتشويه في اللغة.
الكلمات الرئيسية للسياق صعبة بالنسبة لكتاب المواصفات والمترجمين و IDEs. في حالة حدوث حالة أو حالتين خاصتين ، لا يتسبب ذلك في حدوث مشكلات ، ولكن عندما يبدأ استخدامها في كل مكان ، فإنه يترجم إلى تكلفة أعلى بكثير لدعم الكود أو الذيل من الأخطاء.
يمكن للمرء رفض هذا - يقولون ، هذه ليست مشكلة مستخدمي اللغة ، ولكن منشئيها وأولئك الذين يكتبون المترجمين و IDEs. لكن في الواقع ، الجميع يعانون. بالنسبة إلى IDE ، قد تكون هذه مشكلة كبيرة: ستكون هناك حاجة إلى المزيد من المدخلات لتخمين ما يدخله المطور - كلمة رئيسية أو معرف سياق. نتيجة لذلك ، يحصل المستخدمون على تدهور في عمل تسليط الضوء على إمكانات بناء الجملة والإكمال التلقائي وإعادة التجهيز.
يمكنك استخدام هذه الأداة ، لكن قم بذلك بحذر.
تشويه اللسان
يبدو أنه مع المشاكل التي تسببها هذه الأساليب - بناء الجملة الخرقاء ، والمضاعفات غير الضرورية للحياة والبق - من حيث المبدأ ، يمكن أن نتحملها. ولكن هناك مشكلة أخرى ليست المشكلة الأكثر وضوحًا - تؤدي الفروق الدقيقة في استخدام الكلمات الرئيسية إلى حقيقة أن تصميم اللغة نفسها مشوه.
بالنسبة لمطوري Java ، فإن كتابة
واجهة بدلاً من
التعليقات التوضيحية أمر شائع اليوم ، لكن الجميع سيوافقون على أن استخدام مصطلح
التعليق التوضيحي المألوف بدلاً من الجمع بين @ والكلمة الرئيسية "القديمة" سيكون أكثر منطقية.
مثال آخر: لا يمكن اعتبار مجموعة المعدلات المتاحة (عامة ، خاصة ، ساكنة ، نهائية ، إلخ) كاملة - لا يمكننا قول أي شيء
غير نهائي أو
غير ثابت . وهذا بدوره يعني أنه لا يمكنك إنشاء ميزات تكون فيها المتغيرات أو الفئات
نهائية بشكل افتراضي ، أو أن الأعضاء
ثابتون بشكل افتراضي ، حيث لا توجد وسيلة للإشارة إلى أننا نرغب في التخلي عن هذا المعدل.
هذه المشكلة ليست واضحة بالنسبة لأولئك الذين يستخدمون اللغة - لكن مؤلفي اللغة نفسها ، بسبب رغبتهم في تطويرها بشكل أكبر ، يواجهونها باستمرار ، وعلينا جميعًا أن ندفع مقابل هذه القرارات (عندما يكون ذلك صريحًا ، عندما يكون ذلك ضمنيًا).
الاستنتاج من كل ما سبق يشير إلى نفسه: نحن بحاجة إلى مصدر آخر للكلمات الرئيسية.
الحل المقترح
في القدرات التجريبية للغة ، يتم استخدام بناء الجملة لتعيين الكلمات الرئيسية الجديدة مسبقًا ، والتي يسبقها الكلمات الأساسية الجديدة نفسها
بخطين سفليين (على سبيل المثال ، في النموذج الأولي
Project Valhalla ،
__ByValue ). سبب هذا القرار مفهوم - تحتاج إلى الإشارة إلى أن هذا بديل مؤقت ، حيث ستحتاج في المستقبل إلى اتخاذ قرار بشأن بناء الجملة النهائي ، وفي الوقت نفسه يمكنك بسهولة تجنب التعارض مع التعليمات البرمجية الموجودة. يمكن للمرء أن يقترح استخدام تنسيق مشابه للكلمات الرئيسية الجديدة - بدءًا بواحد أو اثنين من الشرطة السفلية - ولكن لا يمكن تسمية هذا الحل الجميل ، لأننا في هذه الحالة سنشوش من الكلمات الرئيسية العادية والجديدة.
لذلك ، يُقترح استخدام الكلمات الأساسية التي تم إنشاؤها باستخدام واصلة ، والتي ستستخدم كلمة رئيسية واحدة أو أكثر أو معرفات محجوزة.
على عكس
الكلمات الرئيسية المقيدة ، فإن هذا النهج سيخلق مشاكل أقل بكثير للتحليل ، لأنه (من الآن فصاعدا - مثال)
لا يمكن الخلط بين
لا معنى لها مع تعبير الطرح ، ويمكن للمكثف أن يحدد دائما ما إذا كان
ab هو ثلاثة رموز أو واحد. بفضل هذا ، تفتح لنا فرص جديدة لإنشاء كلمات رئيسية أقل احتمالًا للتعارض مع شفرة المصدر الحالية أو مع بعضها البعض. علاوة على ذلك ، من الأرجح أن يكون لديهم أسماء ذات معنى ، حيث أن الكثير مما يريد منشئو اللغة إضافته إلى Java يستند إلى بناءات اللغة الموجودة فيه - على سبيل المثال ،
غير فارغة .
كأمثلة للكلمات الرئيسية الجديدة ، يتم تقديم المرشحين المحتملين لمكان الكلمات الرئيسية الجديدة (أذكر أنه وفقًا للمؤلف ، فإن هذه القائمة في هذه اللحظة توضيحية بحتة):
-
غير خالية .
-
غير نهائي ؛
-
حزمة خاصة (معدِّل مستوى الوصول لأعضاء الفصل افتراضيًا ، وهو ما لم يتم الإشارة إليه حاليًا بأي طريقة) ؛
-
قراءة عامة (قراءة علنية ، مسجلة بشكل خاص) ؛
-
لاغية التحقق .
-
نوع ثابت (المفهوم ضروري
لفالله ؛ يدل على ثابت فيما يتعلق بالتخصص المحدد للفئة ، وليس الفئة نفسها) ؛
-
القيمة الافتراضية ؛
- في
نهاية المطاف النهائي (ما يفترض الآن القيام به باستخدام تعليق توضيحي
مستقر ) ،
-
نصف نهائي (كبديل
للمختومة ) ؛
-
التبديل الشامل ؛
-
فئة التعداد ، فئة التعليقات التوضيحية ، فئة السجل (يمكن لمؤلفي اللغة استخدام هذه الكلمات الرئيسية كبديل
للتعداد والواجهة ، إذا كانت لديهم هذه الفرصة) ؛
-
هذه الفئة (لوصف الفصل الحرفي للفئة الحالية) ؛
-
هذا الإرجاع (يُطلب منه غالبًا إضافة طريقة لوضع علامة على أداة تعيين / منشئ الأسلوب كإرجاع مستلمه).
بالتأكيد هناك أشكال أخرى من المخططات المعجمية التي يمكن من خلالها تكوين الكلمات الرئيسية بحيث تتداخل مع الحد الأدنى مع تلك المكتوبة بالفعل بواسطة الكود المصدري. الواصلة المقترحة قابلة للقراءة بما فيه الكفاية لكل من السيارات والبشر.
من المفهوم أن هذا النهج لا يستبعد بأي حال من الأحوال استخدامه مع تلك التي تم استخدامها من قبل ، ولكن سيتم استخدامها جنبا إلى جنب معهم.