كتابة البرامج بلغات ديناميكية تتجاوز ما تسمح به المواصفات

Question

مع نمو اللغات المكتوبة ديناميكيًا، لأنها تمنحنا المزيد من المرونة، هناك احتمال كبير جدًا أن يكتب الأشخاص برامج تتجاوز ما تسمح به المواصفات.

تأثر تفكيري بهذا السؤال عندما قرأت إجابة بوبنس:سؤال حول طرق الشريحة واللصق في JavaScript

الفكر الأساسي هو ذلك splice, في Javascript، تم تحديده للاستخدام في مواقف معينة فقط، ولكن يمكن استخدامه في حالات أخرى، وليس هناك ما يمكن للغة أن تفعله لإيقافه، حيث تم تصميم اللغة لتكون مرنة للغاية.

وما لم يقرأ شخص ما المواصفات ويقرر الالتزام بها، فأنا متأكد تمامًا من حدوث العديد من مثل هذه الانتهاكات.

هل هذه مشكلة أم امتداد طبيعي لكتابة مثل هذه اللغات المرنة؟أم ينبغي لنا أن نتوقع أن تساعد أدوات مثل JSLint في مراقبة المواصفات؟

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

تحديث:

بعد قراءة بعض التعليقات، فكرت في التحقق من طريقة اللصق في المواصفات وهذا ما وجدته، في أسفل الصفحة 104، http://www.mozilla.org/js/language/E262-3.pdf, ، لذلك يبدو أنه يمكنني استخدام لصق على مجموعة من الأطفال دون انتهاك المواصفات.أنا فقط لا أريد أن يتورط الناس في مثالي، ولكن آمل أن يفكروا في السؤال.

    The splice function is intentionally generic; it does not require that its this value be an Array object. 
Therefore it can be transferred to other kinds of objects for use as a method. Whether the splice function 
can be applied successfully to a host object is implementation-dependent.

التحديث 2:أنا لست مهتمًا بكون هذا يتعلق بجافا سكريبت، بل بمرونة اللغة والمواصفات.على سبيل المثال، أتوقع أن مواصفات Java تحدد أنه لا يمكنك وضع التعليمات البرمجية في الواجهة، ولكن باستخدام AspectJ أفعل ذلك بشكل متكرر.من المحتمل أن يكون هذا انتهاكًا، لكن الكتاب لم يتوقعوا AOP وكانت الأداة مرنة بدرجة كافية ليتم ثنيها لهذا الاستخدام، تمامًا كما أن JVM مرن أيضًا بدرجة كافية لـ Scala وClojure.

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

* "من المفترض" لأنني لم أر المواصفات بنفسي.أذهب إلى التصريحات المذكورة أعلاه.