مقدمة

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

اسمحوا لي أن أعرض: UniSharping

كان تقييد C # .NET لحل هذه المشكلة يسمى U # (Universal Sharp) ، وكانت عملية التحويل وأداتها تسمى UniSharping . تتوفر الوحدات والإعدادات والوثائق القابلة للتنفيذ على GitHub ، والنظام مجاني للاستخدام غير التجاري (برنامج مجاني غير تجاري).

من أجل عبر الأنظمة الأساسية ، وضعت Microsoft بالفعل قيودًا على .NET Framework من حيث المكتبات والتقنيات: .NET Core. إنها مثل الخطوة الأولى في الاتجاه الصحيح ، تأخذ U # الخطوة الثانية إلى "قابلية البرمجة المشتركة".

كان هناك عدد قليل من قيود U # في تراكيب اللغة - هذه هي اتهامات goto و goto الحالة ، بالإضافة إلى العائد ، الذي لم يتم تصميمه بشكل كاف في الوضع التلقائي. لا يوصى (على الرغم من أنه من الممكن) استخدام البنية ، هناك فروق دقيقة مع الأسماء - كل هذا موصوف بالتفصيل في مستند منفصل. يقدم المحلل U # أخطاء وتحذيرات ، ولضمان الإنشاء الصحيح ، يجب عليك تعديل شفرة المصدر C # بحيث تختفي تمامًا بشكل مثالي. إذا كنت لا تزال بحاجة إلى الاحتفاظ بالإصدار الأصلي ، فيمكنك استخدام توجيهات المعالج المسبق #if JAVA || PHP ... # آخر ... #endif. تنطبق هذه القيود على مستوى محرك U # ولا تخضع للتصحيح الخارجي ، بالإضافة إلى قائمة اللغات المدعومة.

لكن القيود على مستوى مكتبات النظام لا يتم تعيينها بشكل صارم ويتم تكوينها خارجيًا من خلال ملفات نصية خاصة تحدد كيفية ترجمة فئة معينة وأعضائها إلى اللغة المقابلة. إذا كان هناك تماثلي مباشر ، فيتم الإشارة إليه ، إذا كان الموقف أكثر تعقيدًا ، فإما أن يتم كتابة جزء من رمز اللغة النهائية ، أو بشكل عام فئة (خدمة) خاصة تحل المشكلة المطلوبة. في الحالات الصعبة للغاية ، يجب عليك "رمز ثابت" على مستوى المحرك ، ولكن مثل هذه المواقف نادرة جدًا (حوالي اثني عشر). يتم وصف إجراء إعداد فئات النظام وأعضائها في مستند منفصل. فيما يلي قائمة بفئات C # المدعومة وأعضائها مع نظائرها في Java و Python في الإصدار الحالي على الموقع ، هناك أيضًا عرض توضيحي عبر الإنترنت .

بالنسبة للتكنولوجيا ، تقتصر القائمة الآن على تطبيق وحدة التحكم واختبارات الوحدة (UnitTest). حسنًا ، يتم ترجمة مشاريع Lib الفردية ، كحالة خاصة ، إلى التركيبات المقابلة للغة المطلوبة.

للحصول على ترجمة ناجحة ، يجب أن يحتوي مشروع (الحل) المصدر C # على جزء بدء التشغيل الذي يتحقق من الوظيفة داخل المصدر C #. من الجيد إذا كان هذا نظامًا شاملاً للاختبارات التلقائية (اختبار UnitTest القياسي في عمليات تنفيذ مختلفة أو مكتوبة ذاتيًا) ، ولكن على الأقل يجب أن يكون هناك على الأقل تطبيق وحدة تحكم يعمل بشكل صحيح عند إطلاقه دون أي تدخل من المستخدم. الحاجة إلى ذلك واضحة - بعد جيل في اللغة النهائية ، يمكنك التحقق من الأداء على الفور. من الناحية المثالية ، يجب أن تعمل جميع الاختبارات بشكل مماثل لـ C #.

تاريخ المشروع

فكرة هذا المحول موجودة منذ فترة طويلة. مشروع SDK Pullenti الرئيسي لمعالجة اللغة الطبيعية هو مرشح مثالي للتحويل: كمية كبيرة من التعليمات البرمجية المعقدة والتحسين المستمر. للتكامل مع Java ، كان علي أن أضعه في خدمات الويب ، خوادم TCP ، إلخ.
في الصيف الماضي ، وجدت الوقت والطاقة لخلق الخيار الأول. ترجم مشروع Pullenti إلى Java ، وكذلك هو نفسه في Java.
على مدى الأشهر الستة التالية ، تطور المحول على العديد من المشاريع الداخلية التي كانت في الشركة ، بشكل رئيسي من خلال توسيع فئات النظام.
في ربيع عام 2018 ، جاءت الفكرة لدعم Python ، والتي تم تنفيذها بحلول الصيف. لكن إدراج لغة ثانية لم يتم توفيره في النسخة الأولية واتضح بشكل خرقاء. اضطررت في الصيف إلى إعادة المحرك بالكامل لإمكانيات العديد من اللغات النهائية. أيضًا ، تم نقل إعدادات فئات النظام من الرمز الثابت إلى ملفات نصية خارجية. آمل ألا تتوسع هذه المجموعة بدون مساعدتك.

خطط أخرى هي كما يلي:

• اسحب Python إلى مستوى Java. يتم دعم Python الآن على مستوى Pullenti ، لكن Java تقدمت كثيرًا في مشاريع أخرى مقارنة بها.
• دعم PHP على الأقل على مستوى مشروع Pullenti.
• دعم C ++. نعم ، أدرك أن هذا صعب للغاية ، لأنه من غير الواضح عند تحرير الذاكرة أي مؤشر هو الرابط والذي يجب حذفه. ولكن هناك أفكار ...

من يستطيع أن يكون في متناول اليد

في الغالب أولئك الذين يطورون حزم SDK محتملة عبر الأنظمة الأساسية في C # بفضل محول UniSharping ، يمكن أيضًا أن تصبح SDK الخاصة بهم "برامج شاملة" ، مما سيوسع دائرة المستخدمين المحتملين.
في الآونة الأخيرة ، تعززت مواقف STR في روسيا ، والتي أصبحت إلزامية في معظم الوكالات الحكومية وبعض الشركات الكبيرة. اشرح أن .NET Core أيضًا لا يعمل دائمًا ، لأنه "Microsoft". دع بعض الشركات تطور نظام معلوماتها في C #. من أجل إدخال المنتج في "شركة مفتوحة المصدر" ، يمكنك تحديد الجزء المنطقي من المشروع (الواجهة الخلفية) ، وتحويله تلقائيًا إلى إصدارات حسب الضرورة ، وجعل الجزء المرئي (الواجهة الأمامية) في برنامج مفتوح المصدر. أي ، لمواصلة التطوير في C # ، وفي Java فقط الواجهة الأمامية.

أنا لا أستبعد أن من الممكن من حيث المبدأ تحويل مشاريع الويب (مع قيود ، بالطبع) ، ولكن ليس لدي المهارات والمعلومات اللازمة لذلك. إذا رأى أي شخص مثل هذه الفرصة ، فمن الممكن تمامًا تنفيذها في UniSharping.

ألاحظ أنه بالنسبة لمشروع C # المعقد الحقيقي ، سيتطلب دعم Java أو لغة أخرى بعض الجهد لتعديل الكود ، وتسليط الضوء على الجزء المحمول في المشروع ، و "تطويقه" باختبارات الوحدة. أيضًا ، لا يزال إعداد فئات وأساليب النظام غير المدعومة وإصلاح أخطاء UniSharping نفسها (بمساعدتي) هو العمل. لكن العملية متقاربة ، وفي النهاية يتوقع المشروع مكافأة عبر مبرمج.