البرمجة التفاعلية

أكثر طرق نشر البيانات شيوعاً هي:

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

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

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

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

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

هناك طريقتان رئيسيتان تُستخدمان لبناء مخطط التبعية :

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

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

t = ثانية + 1 g = (t > ثانية) 

بما أن قيمة tيجب أن تكون دائمًا أكبر من seconds، فإن هذا التعبير يجب أن يُقيّم دائمًا إلى قيمة صحيحة. لسوء الحظ، قد يعتمد هذا على ترتيب التقييم. عند secondsتغيير ، يجب تحديث تعبيرين: seconds + 1والشرط. إذا تم تقييم الأول قبل الثاني، فسيظل هذا الشرط صحيحًا. أما إذا تم تحديث الشرط أولًا، باستخدام القيمة القديمة لـ tوالقيمة الجديدة لـ seconds، فسيُقيّم التعبير إلى قيمة خاطئة. يُسمى هذا خللًا .

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

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

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

في بعض الحالات، من الممكن التوصل إلى حلول جزئية مبنية على أسس علمية. ومن هذه الحلول:

• قد تُقدّم لغة برمجة مفهوم "الخلية القابلة للتغيير". الخلية القابلة للتغيير هي خلية يكون نظام التحديث التفاعلي على دراية بها، بحيث تنتقل التغييرات التي تُجرى عليها إلى باقي أجزاء البرنامج التفاعلي. يُمكّن هذا الجزء غير التفاعلي من البرنامج من إجراء تغيير تقليدي، بينما يُمكّن الكود التفاعلي من إدراك هذا التحديث والاستجابة له، وبالتالي الحفاظ على اتساق العلاقة بين القيم في البرنامج. ومن الأمثلة على لغات البرمجة التفاعلية التي تُوفّر مثل هذه الخلية لغة FrTime. ^{[ 4 ]}
• توفر المكتبات الموجهة للكائنات والمغلفة بشكل صحيح مفهومًا مغلفًا للحالة. من حيث المبدأ، يُمكن لهذه المكتبة التفاعل بسلاسة مع الجزء التفاعلي من اللغة. على سبيل المثال، يُمكن تثبيت دوال رد النداء في دوال الوصول (getters) الخاصة بالمكتبة الموجهة للكائنات لإعلام محرك التحديث التفاعلي بتغييرات الحالة، كما يُمكن دفع التغييرات في المكون التفاعلي إلى المكتبة الموجهة للكائنات من خلال دوال الوصول. تستخدم مكتبة FrTime هذه الاستراتيجية. ^{[ 5 ]}

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

t = إذا كان (باقي قسمة الثواني على 2) يساوي صفرًا: ثانية + 1 آخر: ثانية - 1 نهاية t + 1 

في كل ثانية، تتغير قيمة هذا التعبير إلى تعبير تفاعلي مختلف، والذي t + 1يعتمد بدوره على التعبير الآخر. لذلك، يتم تحديث مخطط التبعيات كل ثانية.

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

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