रिएक्टिव प्रोग्रामिंग: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| (11 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{short description|Programming paradigm based on asynchronous data streams}} | {{short description|Programming paradigm based on asynchronous data streams}} | ||
{{Programming paradigms}} | {{Programming paradigms}} | ||
[[ कम्प्यूटिंग ]] में, प्रतिक्रियाशील प्रोग्रामिंग [[स्ट्रीम (कंप्यूटिंग)]] और परिवर्तन के प्रसार से संबंधित | [[ कम्प्यूटिंग | कम्प्यूटिंग]] में, प्रतिक्रियाशील प्रोग्रामिंग [[स्ट्रीम (कंप्यूटिंग)]] और परिवर्तन के प्रसार से संबंधित [[घोषणात्मक प्रोग्रामिंग|कथनात्मक प्रोग्रामिंग]] [[प्रोग्रामिंग प्रतिमान]] है। इस प्रतिमान के साथ, स्थैतिक (जैसे, सरणियाँ) या गतिशील (जैसे, घटना उत्सर्जक) डेटा स्ट्रीम को सरलता से व्यक्त करना संभव है, और यह भी संप्रेषित करता है कि संबद्ध निष्पादन मॉडल के अन्दर अनुमानित निर्भरता उपस्थित है | जो बदले हुए डेटा के स्वत: प्रसार की सुविधा प्रदान करता है। | ||
उदाहरण के लिए, | उदाहरण के लिए, अनिवार्य प्रोग्रामिंग सेटिंग में, <code>a := b + c</code> इसका कारण होगा कि <code>a</code> का <code>b + c</code> परिणाम दिया जा रहा है | जब अभिव्यक्ति का मूल्यांकन किया जाता है, और बाद में, <code>b</code> और <code>c</code> के मान बिना किसी प्रभाव के बदला जा सकता है | <code>a</code>. के मूल्य पर दूसरी ओर, प्रतिक्रियाशील प्रोग्रामिंग में,<code>a</code> का मूल्य स्वचालित रूप से अपडेट हो जाते हैं | जब भी के मान <code>b</code> या <code>c</code> परिवर्तन, प्रोग्राम के बिना बयान को स्पष्ट रूप से फिर से निष्पादित करने के लिए <code>a := b + c</code> के वर्तमान में आवंटित मूल्य का निर्धारण करने के लिए होता है | | ||
{{sxhl|2=javascript|1= | {{sxhl|2=javascript|1= | ||
var b = 1 | var b = 1 | ||
| Line 21: | Line 20: | ||
}} | }} | ||
एक अन्य उदाहरण | एक अन्य उदाहरण [[हार्डवेयर विवरण भाषा]] है | जैसे कि [[Verilog|वेरिलॉग]], जहां प्रतिक्रियाशील प्रोग्रामिंग परिवर्तनों को मॉडलिंग करने में सक्षम बनाती है | क्योंकि वे परिपथ के माध्यम से प्रचार करते हैं। | ||
प्रतिक्रियाशील प्रोग्रामिंग को इंटरैक्टिव यूजर इंटरफेस और निकट-वास्तविक समय सिस्टम एनीमेशन के निर्माण को सरल बनाने के विधि के रूप में प्रस्तावित किया गया है। | |||
उदाहरण के लिए, मॉडल-व्यू-कंट्रोलर (एमवीसी) आर्किटेक्चर में, प्रतिक्रियाशील प्रोग्रामिंग अंतर्निहित मॉडल में परिवर्तन की सुविधा प्रदान कर सकती है | जो संबंधित दृश्य में स्वचालित रूप से परिलक्षित होती है।<ref name="refTrellis">{{Citation | url = http://peak.telecommunity.com/DevCenter/Trellis#model-view-controller-and-the-observer-pattern | title = Model-view-controller and the observer pattern | last = Trellis | publisher = Tele community}}.</ref> | |||
== प्रतिक्रियाशील प्रोग्रामिंग भाषाएँ बनाने के लिए दृष्टिकोण == | == प्रतिक्रियाशील प्रोग्रामिंग भाषाएँ बनाने के लिए दृष्टिकोण == | ||
प्रतिक्रियाशील प्रोग्रामिंग भाषाओं के निर्माण में कई लोकप्रिय दृष्टिकोण कार्यरत हैं। समर्पित भाषाओं की विशिष्टता जो विभिन्न डोमेन बाधाओं के लिए विशिष्ट हैं। ऐसी बाधाओं को | प्रतिक्रियाशील प्रोग्रामिंग भाषाओं के निर्माण में कई लोकप्रिय दृष्टिकोण कार्यरत हैं। समर्पित भाषाओं की विशिष्टता जो विभिन्न डोमेन बाधाओं के लिए विशिष्ट हैं। ऐसी बाधाओं को सामान्यतः रीयल-टाइम, एम्बेडेड कंप्यूटिंग या हार्डवेयर विवरण द्वारा वर्णित किया जाता है। एक अन्य दृष्टिकोण में सामान्य-उद्देश्य वाली भाषाओं के विनिर्देश सम्मिलित हैं | जिनमें प्रतिक्रियाशीलता के लिए समर्थन सम्मिलित है। अन्य दृष्टिकोणों को परिभाषा में व्यक्त किया गया है, और प्रोग्रामिंग लाइब्रेरी, या एम्बेडेड [[डोमेन-विशिष्ट भाषा]]ओं का उपयोग, जो प्रोग्रामिंग भाषा के साथ या शीर्ष पर प्रतिक्रियाशीलता को सक्षम करता है। विशिष्टता और इन विभिन्न दृष्टिकोणों के उपयोग के परिणामस्वरूप भाषा क्षमता व्यापार-नापसंद हो जाती है। सामान्यतः, भाषा जितनी अधिक प्रतिबंधित होती है | उससे जुड़े संकलक और विश्लेषण उपकरण डेवलपर्स को सूचित करने में सक्षम होते हैं | (उदाहरण के लिए, वास्तविक वास्तविक समय में प्रोग्राम निष्पादित करने में सक्षम हैं या नहीं, इसके लिए विश्लेषण करने में)। विशिष्टता में कार्यात्मक व्यापार-नापसंद का परिणाम किसी भाषा की सामान्य प्रयोज्यता में गिरावट हो सकता है। | ||
== प्रोग्रामिंग मॉडल और | == प्रोग्रामिंग मॉडल और सिमेंटिक्स == | ||
विभिन्न प्रकार के मॉडल और | विभिन्न प्रकार के मॉडल और सिमेंटिक्स प्रतिक्रियाशील प्रोग्रामिंग को नियंत्रित करते हैं। हम उन्हें निम्नलिखित आयामों में शिथिल रूप से विभाजित कर सकते हैं | | ||
* तुल्यकालिक: समय का तुल्यकालिक बनाम अतुल्यकालिक मॉडल | * तुल्यकालिक: समय का तुल्यकालिक बनाम अतुल्यकालिक मॉडल | ||
* | * निर्धारणवाद: नियतात्मक बनाम गैर-नियतात्मक मूल्यांकन प्रक्रिया और परिणाम | ||
* | * अपडेट प्रक्रिया: [[कॉलबैक (कंप्यूटर प्रोग्रामिंग)]] बनाम डेटाफ्लो बनाम एक्टर | ||
== कार्यान्वयन | == कार्यान्वयन विधिया और चुनौतियाँ == | ||
=== कार्यान्वयन का सार === | === कार्यान्वयन का सार === | ||
प्रतिक्रियाशील प्रोग्रामिंग भाषा रनटाइम को | प्रतिक्रियाशील प्रोग्रामिंग भाषा रनटाइम को ग्राफ़ द्वारा दर्शाया जाता है | जो सम्मिलित प्रतिक्रियाशील मूल्यों के बीच निर्भरता की पहचान करता है। इस तरह के ग्राफ में, नोड्स कंप्यूटिंग और किनारों के मॉडल निर्भरता संबंधों के कार्य का प्रतिनिधित्व करते हैं। इस तरह के रनटाइम ने उक्त ग्राफ को नियोजित किया है | जिससे यह विभिन्न संगणनाओं पर दृष्टी रखने में सहायता करता है | जिसे नए सिरे से निष्पादित किया जाना चाहिए | एक बार इसमें सम्मिलित इनपुट मान बदल जाता है। | ||
==== प्रचार एल्गोरिदम बदलें ==== | ==== प्रचार एल्गोरिदम बदलें ==== | ||
डेटा प्रसार के सबसे | डेटा प्रसार के सबसे सामान्य विधि हैं | | ||
* पुल: मूल्य उपभोक्ता वास्तव में 'सक्रिय' है | जिसमें यह नियमित रूप से मूल्यों के लिए देखे गए स्रोत से पूछताछ करता है और जब भी कोई प्रासंगिक मूल्य उपलब्ध होता है तो प्रतिक्रिया करता है । घटनाओं या मूल्य परिवर्तनों के लिए नियमित रूप से जाँच करने के इस अभ्यास को सामान्यतः ''पोलिंग'' कहा जाता है। | |||
* पुश: जब भी मूल्य उपलब्ध हो जाता है तो मूल्य उपभोक्ता स्रोत से मूल्य प्राप्त करता है। ये मूल्य स्व-निहित हैं | उदाहरण उनमें सभी आवश्यक जानकारी होती है, और उपभोक्ता द्वारा और कोई जानकारी पूछने की आवश्यकता नहीं होती है। | |||
* पुश-पुल: मूल्य उपभोक्ता को ''परिवर्तन सूचना'' प्राप्त होती है | जो परिवर्तन का संक्षिप्त विवरण है, उदाहरण. कुछ मूल्य बदल गए - यह 'पुश' भाग है। चूँकि, अधिसूचना में सभी आवश्यक जानकारी नहीं होती है | (जिसका अर्थ है कि इसमें वास्तविक मान सम्मिलित नहीं हैं), इसलिए उपभोक्ता को अधिसूचना प्राप्त होने के बाद अधिक जानकारी (विशिष्ट मूल्य) के लिए स्रोत से पूछताछ करने की आवश्यकता है | यह'' पुल' भाग. इस पद्धति का सामान्यतः उपयोग तब किया जाता है | जब बड़ी मात्रा में डेटा होता है | जिसमें उपभोक्ताओं की संभावित रुचि हो सकती है। इसलिए थ्रूपुट और विलंबता को कम करने के लिए, केवल हल्के-फुल्के नोटिफिकेशन भेजे जाते हैं; और फिर जिन उपभोक्ताओं को अधिक जानकारी की आवश्यकता है | वे उस विशिष्ट जानकारी का अनुरोध करेंगे। इस दृष्टिकोण में यह दोष भी है कि सूचना भेजे जाने के बाद स्रोत अतिरिक्त जानकारी के लिए कई अनुरोधों से अभिभूत हो सकता है।'' | |||
==== पुश के लिए क्या? ==== | |||
कार्यान्वयन स्तर पर, घटना की प्रतिक्रिया में ग्राफ की जानकारी में प्रसार होता है | जो परिवर्तन के अस्तित्व को दर्शाता है। परिणाम स्वरुप, ऐसे परिवर्तन से प्रभावित होने वाली संगणनाएं पुरानी हो जाती हैं और उन्हें फिर से निष्पादन के लिए फ़्लैग किया जाना चाहिए। इस तरह की संगणनाओं को सामान्यतः इसके संबद्ध स्रोत में परिवर्तन के [[सकर्मक बंद]] होने की विशेषता होती है। प्रसार परिवर्तन से ग्राफ़ के सिंक के मान में अपडेट हो सकता है। | |||
डेल्टा प्रसार | ग्राफ़ प्रचारित जानकारी में नोड की पूर्ण स्थिति सम्मिलित हो सकती है, अर्थात, सम्मिलित नोड का संगणना परिणाम ऐसे स्थितियों में, नोड के पिछले आउटपुट को तब अनदेखा कर दिया जाता है। एक अन्य विधि में डेल्टा प्रचार अर्थात वृद्धिशील परिवर्तन प्रसार सम्मिलित है। इस स्थिति में, सूचना को ग्राफ के किनारों के साथ फैलाया जाता है | जिसमें केवल डेल्टा होते हैं | जो बताते हैं कि पिछले नोड को कैसे बदला गया था। यह दृष्टिकोण विशेष रूप से महत्वपूर्ण है | जब नोड्स बड़ी मात्रा में स्तर डेटा रखते हैं | | ||
डेल्टा प्रसार अनिवार्य रूप से अनुकूलन है | जिसे [[वृद्धिशील कंप्यूटिंग]] के अनुशासन के माध्यम से बड़े मापदंड पर अध्ययन किया गया है | जिसके दृष्टिकोण में [[डेटाबेस]] External.2सी वैचारिक.2सी और आंतरिक विचारों दृश्य-अपडेट समस्या को सम्मिलित करते हुए रनटाइम संतुष्टि की आवश्यकता होती है। यह समस्या डेटाबेस संस्थाओं के उपयोग के लिए बदनाम है | जो बदलते डेटा दृश्यों के रखरखाव के लिए उत्तरदायी हैं। | |||
एक अन्य सामान्य अनुकूलन एकात्मक परिवर्तन संचय और बैच प्रसार का रोजगार है। ऐसा समाधान तेजी से हो सकता है | क्योंकि यह सम्मिलित नोड्स के बीच संचार को कम करता है। अनुकूलन रणनीतियों को तब नियोजित किया जा सकता है | जो अन्दर निहित परिवर्तनों की प्रकृति के बारे में तर्क देते हैं और तदनुसार परिवर्तन करते हैं। उदाहरण. बैच में दो परिवर्तन एक दूसरे को रद्द कर सकते हैं, और इस प्रकार, केवल अनदेखा किया जा सकता है। फिर भी एक और उपलब्ध दृष्टिकोण अमान्यता अधिसूचना प्रचार के रूप में वर्णित है। यह दृष्टिकोण अद्यतनों को खींचने के लिए अमान्य इनपुट वाले नोड्स का कारण बनता है | इस प्रकार परिणामस्वरूप अपने स्वयं के आउटपुट का अपडेट होता है। | |||
[[निर्भरता ग्राफ]] के निर्माण में नियोजित दो प्रमुख विधि हैं | | |||
# निर्भरता का ग्राफ घटना लूप के अन्दर निहित रूप से बनाए रखा जाता है। स्पष्ट कॉलबैक का पंजीकरण, जिसके परिणामस्वरूप अंतर्निहित निर्भरताओं का निर्माण होता है। इसलिए, नियंत्रण उलटा, जो कॉलबैक के माध्यम से प्रेरित होता है | इस प्रकार छोड़ दिया जाता है। चूँकि, कॉलबैक को कार्यात्मक बनाना (अर्थात इकाई मूल्य के अतिरिक्त स्तर मूल्य लौटाना) आवश्यक है कि इस तरह के कॉलबैक संरचनागत हों जाता है । | |||
# निर्भरता का ग्राफ प्रोग्राम-विशिष्ट है और प्रोग्रामर द्वारा उत्पन्न किया गया है। यह कॉलबैक के नियंत्रण व्युत्क्रम को दो विधियों से संबोधित करने की सुविधा प्रदान करता है या तो ग्राफ स्पष्ट रूप से निर्दिष्ट किया जाता है |(सामान्यतः डोमेन-विशिष्ट भाषा (डीएसएल) का उपयोग करके, जिसे एम्बेड किया जा सकता है), या ग्राफ को प्रभावी का उपयोग करके अभिव्यक्ति और पीढ़ी के साथ स्पष्ट रूप से परिभाषित किया गया है। | |||
=== | === '''प्रतिक्रियाशील प्रोग्रामिंग में कार्यान्वयन की चुनौतियाँ''' === | ||
==== अस्तव्यस्तता ==== | |||
< | परिवर्तनों का प्रचार करते समय, प्रचार आदेश चुनना संभव है | जैसे अभिव्यक्ति का मूल्य स्रोत प्रोग्राम का प्राकृतिक परिणाम नहीं है। इसे हम उदाहरण से सरलता से समझ सकते हैं। कल्पना करना <code>seconds</code> प्रतिक्रियाशील मान है जो वर्तमान समय (सेकेंड में) का प्रतिनिधित्व करने के लिए प्रत्येक सेकंड बदलता है। इस अभिव्यक्ति पर विचार करें |<syntaxhighlight lang="abl"> | ||
t = seconds + 1 | |||
g = (t > seconds) | |||
</ | </syntaxhighlight> | ||
[[File:Reactive programming glitches.svg|thumb]]क्योंकि <code>t</code> से | [[File:Reactive programming glitches.svg|thumb]]क्योंकि <code>t</code> से <code>seconds</code>, सदैव बड़ा होना चाहिए | इस अभिव्यक्ति का मूल्यांकन सदैव सही मान पर होना चाहिए। यह मूल्यांकन के क्रम पर निर्भर कर सकता है। जब <code>seconds</code> परिवर्तन, दो भावों को अपडेट करना है | <code>seconds + 1</code> और सशर्त यदि पहला दूसरे से पहले मूल्यांकन करता है, तो यह अपरिवर्तनीय होगा। यदि, चूँकि, सशर्त अपडेट पहले, के पुराने मान का उपयोग करते हुए <code>t</code> और <code>seconds</code> का नया मूल्य , तब व्यंजक का मूल्यांकन गलत मान पर होगा। इसे अस्तव्यस्तता कहते हैं। | ||
कुछ प्रतिक्रियाशील भाषाएँ | कुछ प्रतिक्रियाशील भाषाएँ अस्तव्यस्त-मुक्त हैं, और इस गुण को सिद्ध करती हैं | यह सामान्यतः [[टोपोलॉजिकल सॉर्टिंग]] एक्सप्रेशंस और टोपोलॉजिकल ऑर्डर में अपडेटिंग वैल्यू द्वारा हासिल किया जाता है। चूँकि, इसके प्रदर्शन निहितार्थ हो सकते हैं, जैसे मूल्यों के वितरण में देरी (प्रसार के क्रम के कारण)। इसलिए, कुछ स्थितियों में, प्रतिक्रियाशील भाषाएँ अस्तव्यस्तता की अनुमति देती हैं, और डेवलपर्स को इस संभावना के बारे में पता होना चाहिए कि मान अस्थायी रूप से प्रोग्राम स्रोत के अनुरूप होने में विफल हो सकते हैं, और यह कि कुछ अभिव्यक्तियाँ कई बार मूल्यांकन कर सकती हैं |(उदाहरण के लिए, <code>t > seconds</code> दो बार मूल्यांकन कर सकते हैं | एक बार जब का नया मान <code>seconds</code> आता है, और एक बार फिर कब <code>t</code> अपडेट) होता है। | ||
==== चक्रीय निर्भरता ==== | ==== चक्रीय निर्भरता ==== | ||
निर्भरता की सामयिक छँटाई निर्भरता ग्राफ पर निर्भर करती है जो | निर्भरता की सामयिक छँटाई निर्भरता ग्राफ पर निर्भर करती है | जो निर्देशित विश्वकोश ग्राफ (डीएजी) है। व्यवहार में, प्रोग्राम निर्भरता ग्राफ को परिभाषित कर सकता है | जिसमें चक्र होते हैं। सामान्यतः, प्रतिक्रियाशील प्रोग्रामिंग भाषाएं उम्मीद करती हैं कि प्रतिक्रियात्मक अपडेट को समाप्त करने की अनुमति देने के लिए कुछ तत्वों को पीछे के किनारे पर रखकर ऐसे चक्रों को तोड़ा जा सकता है। सामान्यतः, भाषाएं ऑपरेटर प्रदान करती हैं | जैसे <code>delay</code> इस उद्देश्य के लिए अपडेट तंत्र द्वारा उपयोग किया जाता है | क्योंकि a <code>delay</code> तात्पर्य यह है कि अगली बार चरण में क्या मूल्यांकन किया जाना चाहिए (वर्तमान मूल्यांकन को समाप्त करने की अनुमति)। | ||
==== परिवर्तनशील अवस्था के साथ सहभागिता ==== | ==== परिवर्तनशील अवस्था के साथ सहभागिता ==== | ||
प्रतिक्रियाशील भाषाएँ | प्रतिक्रियाशील भाषाएँ सामान्यतः मानती हैं कि उनके भाव शुद्ध कार्य हैं। यह अपडेट तंत्र को अपडेट करने के लिए अलग-अलग ऑर्डर चुनने की अनुमति देता है, और विशिष्ट आदेश को अनिर्दिष्ट छोड़ देता है |(जिससे अनुकूलन सक्षम होता है)। जब प्रतिक्रियाशील भाषा स्तर के साथ प्रोग्रामिंग भाषा में एम्बेड की जाती है | चूँकि, प्रोग्रामर के लिए उत्परिवर्तनीय संचालन करना संभव हो सकता है। इस अंतःक्रिया को सुगम कैसे बनाया जाए यह खुली समस्या बनी हुई है। | ||
कुछ स्थितियों में सैद्धांतिक आंशिक समाधान संभव है। ऐसे दो समाधानों में सम्मिलित हैं: | |||
==== निर्भरता के ग्राफ का गतिशील | * भाषा उत्परिवर्तनीय कोशिका की धारणा प्रस्तुत कर सकती है। परिवर्तनशील सेल वह है जिसके बारे में प्रतिक्रियाशील अपडेट प्रणाली को पता होता है | जिससे कि सेल में किए गए परिवर्तन बाकी प्रतिक्रियाशील प्रोग्राम में फैल जाते हैं। यह प्रोग्राम के गैर-प्रतिक्रियाशील भाग को पारंपरिक उत्परिवर्तन करने में सक्षम बनाता है | जबकि प्रतिक्रियाशील कोड को इस अपडेट के बारे में जागरूक होने और प्रतिक्रिया देने में सक्षम बनाता है | इस प्रकार प्रोग्राम में मूल्यों के बीच संबंधों की निरंतरता बनाए रखता है। ऐसी सेल प्रदान करने वाली प्रतिक्रियाशील भाषा का उदाहरण फ्रटाइम है।<ref>{{Cite web|url=http://cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/|title=कॉल-बाय-वैल्यू लैंग्वेज में डायनेमिक डेटाफ्लो एम्बेड करना|website=cs.brown.edu|access-date=2016-10-09}}</ref> | ||
* उचित रूप से एनकैप्सुलेटेड ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी स्तर की एनकैप्सुलेटेड धारणा प्रस्तुत करती है। सिद्धांत रूप में, इस तरह के पुस्तकालय के लिए किसी भाषा के प्रतिक्रियाशील भाग के साथ सुचारू रूप से चलाना करना संभव है। उदाहरण के लिए, स्तर परिवर्तनों के बारे में प्रतिक्रियाशील अपडेट इंजन को सूचित करने के लिए ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी के गेटर्स में कॉलबैक स्थापित किए जा सकते हैं, और प्रतिक्रियाशील घटक में परिवर्तन गेटर्स के माध्यम से ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी में धकेले जा सकते हैं। फ्रटाइम ऐसी रणनीति अपनाता है।<ref>{{Cite web|url=http://cs.brown.edu/~sk/Publications/Papers/Published/ick-adapt-oo-fwk-frp/|title=Crossing State Lines: Adapting Object-Oriented Frameworks to Functional Reactive Languages|website=cs.brown.edu|access-date=2016-10-09}}</ref> | |||
==== निर्भरता के ग्राफ का गतिशील अपडेट ==== | |||
कुछ प्रतिक्रियाशील भाषाओं में, निर्भरता का ग्राफ स्थिर होता है, अर्थात, | कुछ प्रतिक्रियाशील भाषाओं में, निर्भरता का ग्राफ स्थिर होता है, अर्थात, प्रोग्राम के निष्पादन के समय ग्राफ स्थिर रहता है। अन्य भाषाओं में, ग्राफ़ गतिशील हो सकता है, अर्थात यह प्रोग्राम के निष्पादन के रूप में बदल सकता है। साधारण उदाहरण के लिए, इस उदाहरण पर विचार करें (जहाँ <code>seconds</code> प्रतिक्रियाशील मूल्य है)<syntaxhighlight> | ||
< | t = | ||
if ((seconds mod 2) == 0): | |||
seconds + 1 | |||
else: | |||
seconds - 1 | |||
end | |||
t + 1 | |||
</syntaxhighlight>प्रत्येक सेकेंड, इस अभिव्यक्ति का मूल्य अलग प्रतिक्रियाशील अभिव्यक्ति में बदल जाता है | जो <code>t + 1</code> तो निर्भर करता है। इसलिए, निर्भरता का ग्राफ प्रत्येक सेकंड अपडेट होता है। | |||
</ | |||
प्रत्येक सेकेंड, इस अभिव्यक्ति का मूल्य | |||
निर्भरता के गतिशील | निर्भरता के गतिशील अपडेट की अनुमति देने से महत्वपूर्ण अभिव्यंजक शक्ति मिलती है (उदाहरण के लिए, [[ ग्राफिकल यूज़र इंटरफ़ेस |ग्राफिकल यूज़र इंटरफ़ेस]] (जीयूआई) प्रोग्रामो में गतिशील निर्भरता नियमित रूप से होती है)। चूँकि, प्रतिक्रियाशील अपडेट इंजन को यह तय करना होगा कि क्या प्रत्येक बार अभिव्यक्ति का पुनर्निर्माण करना है, या अभिव्यक्ति के नोड को निर्मित किन्तु निष्क्रिय रखना है | बाद वाले स्थिति में, सुनिश्चित करें कि वे गणना में भाग नहीं लेते हैं | जब उन्हें सक्रिय नहीं माना जाता है। | ||
== अवधारणाएं == | == अवधारणाएं == | ||
=== स्पष्टता की डिग्री === | === स्पष्टता की डिग्री === | ||
रिएक्टिव प्रोग्रामिंग | रिएक्टिव प्रोग्रामिंग भाषा बहुत स्पष्ट लोगों से लेकर हो सकती हैं | जहां तीरों का उपयोग करके डेटा प्रवाह स्थापित किया जाता है | जहां डेटा प्रवाह उन भाषा निर्माणों से प्राप्त होता है | जो अनिवार्य या कार्यात्मक प्रोग्रामिंग के समान दिखते हैं। उदाहरण के लिए, अनुमानित रूप से उठाए गए [[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] (एफआरपी) में फ़ंक्शन कॉल डेटा प्रवाह ग्राफ़ में नोड का निर्माण करने के लिए अंतर्निहित रूप से कारण हो सकता है। गतिशील भाषाओं के लिए प्रतिक्रियाशील प्रोग्रामिंग लाइब्रेरी (जैसे कि लिस्प सेल और पायथन ट्रेलिस लाइब्रेरी) फ़ंक्शन के निष्पादन के समय पढ़े गए मानों के रनटाइम विश्लेषण से निर्भरता ग्राफ का निर्माण कर सकते हैं | डेटा प्रवाह विनिर्देशों को निहित और गतिशील दोनों होने की अनुमति देते हैं। | ||
कभी-कभी रिएक्टिव प्रोग्रामिंग शब्द सॉफ्टवेयर इंजीनियरिंग के | कभी-कभी रिएक्टिव प्रोग्रामिंग शब्द सॉफ्टवेयर इंजीनियरिंग के आर्किटेक्चर स्तर को संदर्भित करता है | जहां डेटा प्रवाह ग्राफ में अलग-अलग नोड सामान्य प्रोग्राम होते हैं | जो एक दूसरे के साथ संवाद करते हैं। | ||
=== स्थिर या गतिशील === | === स्थिर या गतिशील === | ||
प्रतिक्रियाशील प्रोग्रामिंग विशुद्ध रूप से स्थिर हो सकती है जहां डेटा प्रवाह स्थिर रूप से सेट किया जाता है, या गतिशील हो सकता है जहां प्रोग्राम के निष्पादन के | प्रतिक्रियाशील प्रोग्रामिंग विशुद्ध रूप से स्थिर हो सकती है | जहां डेटा प्रवाह स्थिर रूप से सेट किया जाता है, या गतिशील हो सकता है | जहां प्रोग्राम के निष्पादन के समय डेटा प्रवाह बदल सकता है। | ||
डेटा फ़्लो ग्राफ़ में डेटा स्विच का उपयोग कुछ | डेटा फ़्लो ग्राफ़ में डेटा स्विच का उपयोग कुछ सीमा तक स्थिर डेटा फ्लो ग्राफ़ को गतिशील के रूप में प्रकट कर सकता है, और अंतर को थोड़ा धुंधला कर सकता है। सही प्रतिक्रियाशील प्रोग्रामिंग चूँकि डेटा प्रवाह ग्राफ के पुनर्निर्माण के लिए अनिवार्य प्रोग्रामिंग का उपयोग कर सकती है। | ||
=== उच्च क्रम प्रतिक्रियाशील प्रोग्रामिंग === | === उच्च क्रम प्रतिक्रियाशील प्रोग्रामिंग === | ||
प्रतिक्रियाशील प्रोग्रामिंग को उच्च क्रम का कहा जा सकता है यदि यह इस विचार का समर्थन करता है कि डेटा प्रवाह का उपयोग अन्य डेटा प्रवाह के निर्माण के लिए किया जा सकता है। अर्थात्, डेटा प्रवाह से परिणामी मान | प्रतिक्रियाशील प्रोग्रामिंग को उच्च क्रम का कहा जा सकता है | यदि यह इस विचार का समर्थन करता है कि डेटा प्रवाह का उपयोग अन्य डेटा प्रवाह के निर्माण के लिए किया जा सकता है। अर्थात्, डेटा प्रवाह से परिणामी मान अन्य डेटा प्रवाह ग्राफ़ है | जिसे पहले के समान मूल्यांकन मॉडल का उपयोग करके निष्पादित किया जाता है। | ||
=== डेटा प्रवाह विभेदीकरण === | |||
आदर्श रूप से सभी डेटा परिवर्तनों को तुरंत प्रचारित किया जाता है | किन्तु व्यवहार में यह सुनिश्चित नहीं किया जा सकता है। इसके अतिरिक्त डेटा प्रवाह ग्राफ़ के विभिन्न भागों को अलग-अलग मूल्यांकन प्राथमिकताएँ देना आवश्यक हो सकता है। इसे विभेदित प्रतिक्रियाशील प्रोग्रामिंग कहा जा सकता है ।<ref>{{Cite web|url=http://theartofservice.com/reactive-programming.html|title=Reactive Programming – The Art of Service {{!}} The IT Management Guide|website=theartofservice.com|access-date=2016-07-02}}</ref> | |||
उदाहरण के लिए, वर्ड प्रोसेसर में स्पेलिंग एरर की मार्किंग आवश्यक नहीं कि अक्षरों को डालने के साथ पूरी तरह से सिंक हो। यहाँ विभेदित प्रतिक्रियाशील प्रोग्रामिंग का उपयोग संभावित रूप से वर्तनी परीक्षक को कम प्राथमिकता देने के लिए किया जा सकता है | जिससे अन्य डेटा-प्रवाहों को तात्कालिक रखते हुए इसे विलंबित किया जा सकता है। | |||
उदाहरण के लिए, वर्ड प्रोसेसर में स्पेलिंग एरर की मार्किंग | |||
चूँकि, इस तरह की भिन्नता अतिरिक्त रचना जटिलता का परिचय देती है। उदाहरण के लिए, यह तय करना कि विभिन्न डेटा प्रवाह क्षेत्रों को कैसे परिभाषित किया जाए और विभिन्न डेटा प्रवाह क्षेत्रों के बीच होने वाली घटनाओं को कैसे संभालना है। | |||
=== प्रतिक्रियाशील प्रोग्रामिंग के मूल्यांकन मॉडल === | === प्रतिक्रियाशील प्रोग्रामिंग के मूल्यांकन मॉडल === | ||
प्रतिक्रियाशील | प्रतिक्रियाशील प्रोग्रामो का मूल्यांकन आवश्यक नहीं है कि स्टैक आधारित प्रोग्रामिंग भाषाओं का मूल्यांकन कैसे किया जाता है। इसके अतिरिक्त, जब कुछ डेटा को बदला जाता है, तो परिवर्तन को उन सभी डेटा में प्रचारित किया जाता है | जो बदले गए डेटा से आंशिक रूप से या पूरी तरह से प्राप्त होते हैं । यह परिवर्तन प्रसार कई विधियों से प्राप्त किया जा सकता है | जहाँ संभवतः सबसे स्वाभाविक विधि अमान्य/मंद-पुनर्वैधीकरण योजना है। | ||
यदि डेटा संरचना का निश्चित आकार है, तो संभावित घातीय अपडेट जटिलता के कारण, स्टैक का उपयोग करके केवल सरलता से परिवर्तन का प्रचार करना समस्याग्रस्त हो सकता है। इस तरह के आकार को दोहराए गए हीरे के आकार के रूप में वर्णित किया जा सकता है, और इसकी संरचना निम्न है | | |||
A<sub>n</sub>→B<sub>n</sub>→A<sub>n+1</sub>, A<sub>n</sub>→C<sub>n</sub>→A<sub>n+1</sub>, जहाँ n=1,2... इस समस्या को अमान्यता का प्रचार करके ही दूर किया जा सकता है | जब कुछ डेटा पहले से ही अमान्य नहीं है, और बाद में [[आलसी मूल्यांकन|मंद मूल्यांकन]] का उपयोग करके आवश्यक होने पर डेटा को फिर से मान्य करें। | |||
प्रतिक्रियाशील प्रोग्रामिंग के लिए | प्रतिक्रियाशील प्रोग्रामिंग के लिए अंतर्निहित समस्या यह है कि सामान्य प्रोग्रामिंग भाषा में मूल्यांकन और भूल जाने वाली अधिकांश संगणनाओं को डेटा-संरचनाओं के रूप में स्मृति में प्रदर्शित करने की आवश्यकता होती है। यह संभावित रूप से प्रतिक्रियाशील प्रोग्रामिंग को अत्यधिक मेमोरी खपत कर सकता है। चूँकि, जिसे कम करना कहा जाता है | जिस पर शोध इस समस्या को संभावित रूप से दूर कर सकता है।<ref>{{Citation | url = https://cs.brown.edu/~sk/Publications/Papers/Published/bck-lowering-opt-trans-frp/paper.pdf | first1 = Kimberley | last1 = Burchett | first2 = Gregory H | last2 = Cooper | first3 = Shriram | last3 = Krishnamurthi | contribution = Lowering: a static optimization technique for transparent functional reactivity | title = Proceedings of the 2007 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation | pages = 71–80}}.</ref> | ||
==== प्रेक्षक | दूसरी तरफ, प्रतिक्रियाशील प्रोग्रामिंग ऐसा रूप है जिसे स्पष्ट समांतरता के रूप में वर्णित किया जा सकता है, और इसलिए समानांतर हार्डवेयर की शक्ति का उपयोग करने के लिए फायदेमंद हो सकता है। | ||
रिएक्टिव प्रोग्रामिंग में | |||
==== प्रेक्षक प्रतिरूप के साथ समानताएं ==== | |||
रिएक्टिव प्रोग्रामिंग में सामान्यतः [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] में उपयोग किए जाने वाले ऑब्जर्वर प्रतिरूप के साथ प्रमुख समानताएं होती हैं। चूँकि, डेटा प्रवाह अवधारणाओं को प्रोग्रामिंग भाषा में एकीकृत करने से उन्हें व्यक्त करना सरल हो जाएगा और इसलिए डेटा प्रवाह ग्राफ़ की ग्रैन्युलैरिटी बढ़ सकती है। उदाहरण के लिए, [[पर्यवेक्षक पैटर्न|पर्यवेक्षक प्रतिरूप]] सामान्यतः संपूर्ण वस्तुओं/वर्गों के बीच डेटा-प्रवाह का वर्णन करता है | जबकि ऑब्जेक्ट-ओरिएंटेड प्रतिक्रियाशील प्रोग्रामिंग वस्तुओं/वर्गों के सदस्यों को लक्षित कर सकता है। | |||
== दृष्टिकोण == | == दृष्टिकोण == | ||
=== अनिवार्य === | === अनिवार्य === | ||
सामान्य अनिवार्य प्रोग्रामिंग के साथ प्रतिक्रियाशील प्रोग्रामिंग को फ्यूज करना संभव है। ऐसे प्रतिमान में | सामान्य अनिवार्य प्रोग्रामिंग के साथ प्रतिक्रियाशील प्रोग्रामिंग को फ्यूज करना संभव है। ऐसे प्रतिमान में अनिवार्य प्रोग्राम प्रतिक्रियाशील डेटा संरचनाओं पर काम करते हैं।<ref name="refDC">{{Citation | url = http://dl.acm.org/citation.cfm?id=2048100 | first1 = Camil | last1 = Demetrescu | first2 = Irene | last2 = Finocchi | first3 = Andrea | last3 = Ribichini | contribution = Reactive Imperative Programming with Dataflow Constraints | title = Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications | series = Oopsla '11 | date = 22 October 2011 | pages = 407–26| doi = 10.1145/2048066.2048100 | isbn = 9781450309400 | s2cid = 7285961 }}.</ref> ऐसा सेट-अप कंस्ट्रेंट प्रोग्रामिंग के अनुरूप है | चूँकि, अनिवार्य बाधा प्रोग्रामिंग द्विदिश डेटा-प्रवाह बाधाओं का प्रबंधन करती है | अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग एक तरफ़ा डेटा-प्रवाह बाधाओं का प्रबंधन करती है। | ||
=== | === ऑब्जेक्ट-ओरिएंटेड === | ||
ऑब्जेक्ट-ओरिएंटेड रिएक्टिव प्रोग्रामिंग (ओओआरपी) | ऑब्जेक्ट-ओरिएंटेड रिएक्टिव प्रोग्रामिंग (ओओआरपी) और रिएक्टिव प्रोग्रामिंग का संयोजन है। संभवतः इस तरह के संयोजन को बनाने का सबसे स्वाभाविक विधि इस प्रकार है | विधियों और क्षेत्रों के अतिरिक्त, वस्तुओं में ऐसी प्रतिक्रियाएँ होती हैं | जो स्वचालित रूप से पुनर्मूल्यांकन करती हैं | जब वे अन्य प्रतिक्रियाओं पर निर्भर करती हैं | जिन्हें संशोधित किया गया है। | ||
यदि | यदि ओओआरपी भाषा अपनी अनिवार्य विधियों को बनाए रखती है, तो यह अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग की श्रेणी में भी आएगी। | ||
=== कार्यात्मक === | === कार्यात्मक === | ||
[[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] | [[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] (एफआरपी) [[कार्यात्मक प्रोग्रामिंग]] पर प्रतिक्रियाशील प्रोग्रामिंग के लिए प्रोग्रामिंग प्रतिमान है। | ||
=== एक्टर आधारित === | |||
अभिनेताओं को प्रतिक्रियाशील प्रणालियों को रचना करने का प्रस्ताव दिया गया है | अधिकांशतः कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग के संयोजन में वितरित प्रतिक्रियाशील प्रणालियों को विकसित करने के लिए कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) और [[प्रतिक्रियाशील धाराएँ]] है।<ref name="stella">{{Citation | url = https://drops.dagstuhl.de/opus/volltexte/2020/13176/ | first1 = Sam | last1 = Van den Vonder | first2 = Thierry | last2 = Renaux | first3 = Bjarno | last3 = Oeyen | first4 = Joeri | last4 = De Koster | first5 = Wolfgang | last5 = De Meuter | contribution = Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model | title = Leibniz International Proceedings in Informatics (LIPIcs) | volume = 166 | year = 2020 | pages = 19:1–19:29 | doi = 10.4230/LIPIcs.ECOOP.2020.19| isbn = 9783959771542 }}.</ref><ref name="stella2">{{Citation | url = https://programming-journal.org/2022/6/14/ | first1 = Sam | last1 = Van den Vonder | first2 = Thierry | last2 = Renaux | first3 = Wolfgang | last3 = De Meuter | contribution = Topology-Level Reactivity in Distributed Reactive Programs: Reactive Acquaintance Management using Flocks | title = The Art, Science, and Engineering of Programming | volume = 6:3 | year = 2022 | pages = 14:1–14:36 | doi = 10.22152/programming-journal.org/2022/6/14 }}</ref><ref>{{Citation | url = https://dl.acm.org/doi/10.1145/3281366.3281370 | first1 = Kazuhiro | last1 = Shibanai | first2 = Takuo | last2 = Watanabe | contribution = Distributed Functional Reactive Programming on Actor-Based Runtime | title = Proceedings of the 8th ACM SIGPLAN International Workshop on Programming Based on Actors, Agents, and Decentralized Control | series = Agere 2018 | year = 2018 | pages = 13–22 | doi = 10.1145/3281366.3281370| isbn = 9781450360661 | s2cid = 53113447 }}</ref><ref name="akka">{{cite book | last1=Roestenburg | first1=Raymond | last2=Bakker | first2=Rob | last3=Williams | first3=Rob |year=2016 | title=क्रिया के रूप में| publisher=Manning Publications Co. | location=Greenwich, Connecticut, USA | chapter=13: Streaming | page=281 | isbn=978-1-61729-101-2 }}</ref> | |||
=== नियम आधारित === | === नियम आधारित === | ||
प्रोग्रामिंग भाषाओं की | प्रोग्रामिंग भाषाओं की अपेक्षाकृत नई श्रेणी मुख्य प्रोग्रामिंग अवधारणा के रूप में बाधाओं (नियमों) का उपयोग करती है। इसमें घटनाओं की प्रतिक्रियाएँ होती हैं | जो सभी बाधाओं को संतुष्ट करती हैं। यह न केवल घटना-आधारित प्रतिक्रियाओं को सुविधाजनक बनाता है | किन्तु यह प्रतिक्रियाशील प्रोग्रामो को सॉफ्टवेयर की शुद्धता के लिए महत्वपूर्ण बनाता है। नियम आधारित प्रतिक्रियाशील प्रोग्रामिंग भाषा का उदाहरण एम्परसेंड है | जो [[संबंध बीजगणित]] में स्थापित है।<ref name="refSJ">{{Citation | first1 = Stef | last1 = Joosten | contribution = Relation Algebra as programming language using the Ampersand compiler | title = Journal of Logical and Algebraic Methods in Programming |volume = 100| pages = 113–29|doi = 10.1016/j.jlamp.2018.04.002|year = 2018| s2cid = 52932824 }}.</ref> | ||
== कार्यान्वयन == | == कार्यान्वयन == | ||
* [[ReactiveX]], | * [[ReactiveX|रिएक्टिवएक्स]], आरएक्सजेएस, आरएक्सजावा, आरएक्सनेट, आरएक्सपीवाई और आरएक्सस्विफ्ट सहित कई भाषा कार्यान्वयन के साथ स्ट्रीम, ऑब्जर्वेबल और ऑपरेटरों के साथ प्रतिक्रियाशील प्रोग्रामिंग को प्रयुक्त करने के लिए एपीआई होता है। | ||
* [[एल्म (प्रोग्रामिंग भाषा)]] वेब यूजर इंटरफेस की प्रतिक्रियाशील रचना। | * [[एल्म (प्रोग्रामिंग भाषा)]] वेब यूजर इंटरफेस की प्रतिक्रियाशील रचना। | ||
* रिएक्टिव स्ट्रीम, नॉन-ब्लॉकिंग बैकप्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए | * रिएक्टिव स्ट्रीम, नॉन-ब्लॉकिंग बैकप्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए जेवीएम मानक | ||
* [https://github.com/IgorBuchelnikov/ObservableComputations | * [https://github.com/IgorBuchelnikov/ObservableComputations अवलोकनीय संगणनाएँ], क्रॉस-प्लेटफ़ॉर्म .नेट कार्यान्वयन। | ||
* [[Svelte]], | * [[Svelte|स्वेल्ते]], वैरिएंट [[जावास्क्रिप्ट]] सिंटैक्स के रूप में प्रतिक्रियाशीलता लाता है | [[जेएसएक्स (जावास्क्रिप्ट)]] की तरह दिखता है | किन्तु स्वाभाविक रूप से प्रतिक्रियाशील होता है | जहाँ जावास्क्रिप्ट सामान्य रूप से नहीं होता है। | ||
* [https://solidjs.com/ | * [https://solidjs.com/ सॉलिड.js], प्रतिक्रियाशील जेएसएक्स (जावास्क्रिप्ट) टेम्प्लेटिंग के साथ [[जावास्क्रिप्ट सिंटैक्स]] सिमेंटिक्स को बदले बिना जावास्क्रिप्ट में प्रतिक्रियाशीलता लाता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
| Line 180: | Line 170: | ||
==संदर्भ== | ==संदर्भ== | ||
<references/> | <references/> | ||
== बाहरी संबंध == | == बाहरी संबंध == | ||
| Line 190: | Line 179: | ||
* [https://xgrommx.github.io/rx-book/ RxJS], the Reactive Extensions library for "composing asynchronous [...] programs using observable sequences" | * [https://xgrommx.github.io/rx-book/ RxJS], the Reactive Extensions library for "composing asynchronous [...] programs using observable sequences" | ||
* [https://drops.dagstuhl.de/opus/volltexte/2020/13176/ Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model] A 2020 paper that proposes a model of "actors" and "reactors" to avoid the issues that arise when combining imperative code with reactive code. | * [https://drops.dagstuhl.de/opus/volltexte/2020/13176/ Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model] A 2020 paper that proposes a model of "actors" and "reactors" to avoid the issues that arise when combining imperative code with reactive code. | ||
[[Category:Created On 13/05/2023]] | [[Category:Created On 13/05/2023]] | ||
[[Category:Lua-based templates]] | |||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with script errors]] | |||
[[Category:Pages with syntax highlighting errors]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:Templates that add a tracking category]] | |||
[[Category:Templates that generate short descriptions]] | |||
[[Category:Templates using TemplateData]] | |||
[[Category:प्रोग्रामिंग प्रतिमान]] | |||
[[Category:मूल्यांकन रणनीति]] | |||
Latest revision as of 13:36, 15 June 2023
कम्प्यूटिंग में, प्रतिक्रियाशील प्रोग्रामिंग स्ट्रीम (कंप्यूटिंग) और परिवर्तन के प्रसार से संबंधित कथनात्मक प्रोग्रामिंग प्रोग्रामिंग प्रतिमान है। इस प्रतिमान के साथ, स्थैतिक (जैसे, सरणियाँ) या गतिशील (जैसे, घटना उत्सर्जक) डेटा स्ट्रीम को सरलता से व्यक्त करना संभव है, और यह भी संप्रेषित करता है कि संबद्ध निष्पादन मॉडल के अन्दर अनुमानित निर्भरता उपस्थित है | जो बदले हुए डेटा के स्वत: प्रसार की सुविधा प्रदान करता है।
उदाहरण के लिए, अनिवार्य प्रोग्रामिंग सेटिंग में, a := b + c इसका कारण होगा कि a का b + c परिणाम दिया जा रहा है | जब अभिव्यक्ति का मूल्यांकन किया जाता है, और बाद में, b और c के मान बिना किसी प्रभाव के बदला जा सकता है | a. के मूल्य पर दूसरी ओर, प्रतिक्रियाशील प्रोग्रामिंग में,a का मूल्य स्वचालित रूप से अपडेट हो जाते हैं | जब भी के मान b या c परिवर्तन, प्रोग्राम के बिना बयान को स्पष्ट रूप से फिर से निष्पादित करने के लिए a := b + c के वर्तमान में आवंटित मूल्य का निर्धारण करने के लिए होता है |
var b = 1
var c = 2
var a = b + c
b = 10
console.log(a) // 3 (not 12 because "=" is not a reactive assignment operator)
// now imagine you have a special operator "$=" that changes the value of a variable (executes code on the right side of the operator and assigns result to left side variable) not only when explicitly initialized, but also when referenced variables (on the right side of the operator) are changed
var b = 1
var c = 2
var a $= b + c
b = 10
console.log(a) // 12
एक अन्य उदाहरण हार्डवेयर विवरण भाषा है | जैसे कि वेरिलॉग, जहां प्रतिक्रियाशील प्रोग्रामिंग परिवर्तनों को मॉडलिंग करने में सक्षम बनाती है | क्योंकि वे परिपथ के माध्यम से प्रचार करते हैं।
प्रतिक्रियाशील प्रोग्रामिंग को इंटरैक्टिव यूजर इंटरफेस और निकट-वास्तविक समय सिस्टम एनीमेशन के निर्माण को सरल बनाने के विधि के रूप में प्रस्तावित किया गया है।
उदाहरण के लिए, मॉडल-व्यू-कंट्रोलर (एमवीसी) आर्किटेक्चर में, प्रतिक्रियाशील प्रोग्रामिंग अंतर्निहित मॉडल में परिवर्तन की सुविधा प्रदान कर सकती है | जो संबंधित दृश्य में स्वचालित रूप से परिलक्षित होती है।[1]
प्रतिक्रियाशील प्रोग्रामिंग भाषाएँ बनाने के लिए दृष्टिकोण
प्रतिक्रियाशील प्रोग्रामिंग भाषाओं के निर्माण में कई लोकप्रिय दृष्टिकोण कार्यरत हैं। समर्पित भाषाओं की विशिष्टता जो विभिन्न डोमेन बाधाओं के लिए विशिष्ट हैं। ऐसी बाधाओं को सामान्यतः रीयल-टाइम, एम्बेडेड कंप्यूटिंग या हार्डवेयर विवरण द्वारा वर्णित किया जाता है। एक अन्य दृष्टिकोण में सामान्य-उद्देश्य वाली भाषाओं के विनिर्देश सम्मिलित हैं | जिनमें प्रतिक्रियाशीलता के लिए समर्थन सम्मिलित है। अन्य दृष्टिकोणों को परिभाषा में व्यक्त किया गया है, और प्रोग्रामिंग लाइब्रेरी, या एम्बेडेड डोमेन-विशिष्ट भाषाओं का उपयोग, जो प्रोग्रामिंग भाषा के साथ या शीर्ष पर प्रतिक्रियाशीलता को सक्षम करता है। विशिष्टता और इन विभिन्न दृष्टिकोणों के उपयोग के परिणामस्वरूप भाषा क्षमता व्यापार-नापसंद हो जाती है। सामान्यतः, भाषा जितनी अधिक प्रतिबंधित होती है | उससे जुड़े संकलक और विश्लेषण उपकरण डेवलपर्स को सूचित करने में सक्षम होते हैं | (उदाहरण के लिए, वास्तविक वास्तविक समय में प्रोग्राम निष्पादित करने में सक्षम हैं या नहीं, इसके लिए विश्लेषण करने में)। विशिष्टता में कार्यात्मक व्यापार-नापसंद का परिणाम किसी भाषा की सामान्य प्रयोज्यता में गिरावट हो सकता है।
प्रोग्रामिंग मॉडल और सिमेंटिक्स
विभिन्न प्रकार के मॉडल और सिमेंटिक्स प्रतिक्रियाशील प्रोग्रामिंग को नियंत्रित करते हैं। हम उन्हें निम्नलिखित आयामों में शिथिल रूप से विभाजित कर सकते हैं |
- तुल्यकालिक: समय का तुल्यकालिक बनाम अतुल्यकालिक मॉडल
- निर्धारणवाद: नियतात्मक बनाम गैर-नियतात्मक मूल्यांकन प्रक्रिया और परिणाम
- अपडेट प्रक्रिया: कॉलबैक (कंप्यूटर प्रोग्रामिंग) बनाम डेटाफ्लो बनाम एक्टर
कार्यान्वयन विधिया और चुनौतियाँ
कार्यान्वयन का सार
प्रतिक्रियाशील प्रोग्रामिंग भाषा रनटाइम को ग्राफ़ द्वारा दर्शाया जाता है | जो सम्मिलित प्रतिक्रियाशील मूल्यों के बीच निर्भरता की पहचान करता है। इस तरह के ग्राफ में, नोड्स कंप्यूटिंग और किनारों के मॉडल निर्भरता संबंधों के कार्य का प्रतिनिधित्व करते हैं। इस तरह के रनटाइम ने उक्त ग्राफ को नियोजित किया है | जिससे यह विभिन्न संगणनाओं पर दृष्टी रखने में सहायता करता है | जिसे नए सिरे से निष्पादित किया जाना चाहिए | एक बार इसमें सम्मिलित इनपुट मान बदल जाता है।
प्रचार एल्गोरिदम बदलें
डेटा प्रसार के सबसे सामान्य विधि हैं |
- पुल: मूल्य उपभोक्ता वास्तव में 'सक्रिय' है | जिसमें यह नियमित रूप से मूल्यों के लिए देखे गए स्रोत से पूछताछ करता है और जब भी कोई प्रासंगिक मूल्य उपलब्ध होता है तो प्रतिक्रिया करता है । घटनाओं या मूल्य परिवर्तनों के लिए नियमित रूप से जाँच करने के इस अभ्यास को सामान्यतः पोलिंग कहा जाता है।
- पुश: जब भी मूल्य उपलब्ध हो जाता है तो मूल्य उपभोक्ता स्रोत से मूल्य प्राप्त करता है। ये मूल्य स्व-निहित हैं | उदाहरण उनमें सभी आवश्यक जानकारी होती है, और उपभोक्ता द्वारा और कोई जानकारी पूछने की आवश्यकता नहीं होती है।
- पुश-पुल: मूल्य उपभोक्ता को परिवर्तन सूचना प्राप्त होती है | जो परिवर्तन का संक्षिप्त विवरण है, उदाहरण. कुछ मूल्य बदल गए - यह 'पुश' भाग है। चूँकि, अधिसूचना में सभी आवश्यक जानकारी नहीं होती है | (जिसका अर्थ है कि इसमें वास्तविक मान सम्मिलित नहीं हैं), इसलिए उपभोक्ता को अधिसूचना प्राप्त होने के बाद अधिक जानकारी (विशिष्ट मूल्य) के लिए स्रोत से पूछताछ करने की आवश्यकता है | यह पुल' भाग. इस पद्धति का सामान्यतः उपयोग तब किया जाता है | जब बड़ी मात्रा में डेटा होता है | जिसमें उपभोक्ताओं की संभावित रुचि हो सकती है। इसलिए थ्रूपुट और विलंबता को कम करने के लिए, केवल हल्के-फुल्के नोटिफिकेशन भेजे जाते हैं; और फिर जिन उपभोक्ताओं को अधिक जानकारी की आवश्यकता है | वे उस विशिष्ट जानकारी का अनुरोध करेंगे। इस दृष्टिकोण में यह दोष भी है कि सूचना भेजे जाने के बाद स्रोत अतिरिक्त जानकारी के लिए कई अनुरोधों से अभिभूत हो सकता है।
पुश के लिए क्या?
कार्यान्वयन स्तर पर, घटना की प्रतिक्रिया में ग्राफ की जानकारी में प्रसार होता है | जो परिवर्तन के अस्तित्व को दर्शाता है। परिणाम स्वरुप, ऐसे परिवर्तन से प्रभावित होने वाली संगणनाएं पुरानी हो जाती हैं और उन्हें फिर से निष्पादन के लिए फ़्लैग किया जाना चाहिए। इस तरह की संगणनाओं को सामान्यतः इसके संबद्ध स्रोत में परिवर्तन के सकर्मक बंद होने की विशेषता होती है। प्रसार परिवर्तन से ग्राफ़ के सिंक के मान में अपडेट हो सकता है।
ग्राफ़ प्रचारित जानकारी में नोड की पूर्ण स्थिति सम्मिलित हो सकती है, अर्थात, सम्मिलित नोड का संगणना परिणाम ऐसे स्थितियों में, नोड के पिछले आउटपुट को तब अनदेखा कर दिया जाता है। एक अन्य विधि में डेल्टा प्रचार अर्थात वृद्धिशील परिवर्तन प्रसार सम्मिलित है। इस स्थिति में, सूचना को ग्राफ के किनारों के साथ फैलाया जाता है | जिसमें केवल डेल्टा होते हैं | जो बताते हैं कि पिछले नोड को कैसे बदला गया था। यह दृष्टिकोण विशेष रूप से महत्वपूर्ण है | जब नोड्स बड़ी मात्रा में स्तर डेटा रखते हैं |
डेल्टा प्रसार अनिवार्य रूप से अनुकूलन है | जिसे वृद्धिशील कंप्यूटिंग के अनुशासन के माध्यम से बड़े मापदंड पर अध्ययन किया गया है | जिसके दृष्टिकोण में डेटाबेस External.2सी वैचारिक.2सी और आंतरिक विचारों दृश्य-अपडेट समस्या को सम्मिलित करते हुए रनटाइम संतुष्टि की आवश्यकता होती है। यह समस्या डेटाबेस संस्थाओं के उपयोग के लिए बदनाम है | जो बदलते डेटा दृश्यों के रखरखाव के लिए उत्तरदायी हैं।
एक अन्य सामान्य अनुकूलन एकात्मक परिवर्तन संचय और बैच प्रसार का रोजगार है। ऐसा समाधान तेजी से हो सकता है | क्योंकि यह सम्मिलित नोड्स के बीच संचार को कम करता है। अनुकूलन रणनीतियों को तब नियोजित किया जा सकता है | जो अन्दर निहित परिवर्तनों की प्रकृति के बारे में तर्क देते हैं और तदनुसार परिवर्तन करते हैं। उदाहरण. बैच में दो परिवर्तन एक दूसरे को रद्द कर सकते हैं, और इस प्रकार, केवल अनदेखा किया जा सकता है। फिर भी एक और उपलब्ध दृष्टिकोण अमान्यता अधिसूचना प्रचार के रूप में वर्णित है। यह दृष्टिकोण अद्यतनों को खींचने के लिए अमान्य इनपुट वाले नोड्स का कारण बनता है | इस प्रकार परिणामस्वरूप अपने स्वयं के आउटपुट का अपडेट होता है।
निर्भरता ग्राफ के निर्माण में नियोजित दो प्रमुख विधि हैं |
- निर्भरता का ग्राफ घटना लूप के अन्दर निहित रूप से बनाए रखा जाता है। स्पष्ट कॉलबैक का पंजीकरण, जिसके परिणामस्वरूप अंतर्निहित निर्भरताओं का निर्माण होता है। इसलिए, नियंत्रण उलटा, जो कॉलबैक के माध्यम से प्रेरित होता है | इस प्रकार छोड़ दिया जाता है। चूँकि, कॉलबैक को कार्यात्मक बनाना (अर्थात इकाई मूल्य के अतिरिक्त स्तर मूल्य लौटाना) आवश्यक है कि इस तरह के कॉलबैक संरचनागत हों जाता है ।
- निर्भरता का ग्राफ प्रोग्राम-विशिष्ट है और प्रोग्रामर द्वारा उत्पन्न किया गया है। यह कॉलबैक के नियंत्रण व्युत्क्रम को दो विधियों से संबोधित करने की सुविधा प्रदान करता है या तो ग्राफ स्पष्ट रूप से निर्दिष्ट किया जाता है |(सामान्यतः डोमेन-विशिष्ट भाषा (डीएसएल) का उपयोग करके, जिसे एम्बेड किया जा सकता है), या ग्राफ को प्रभावी का उपयोग करके अभिव्यक्ति और पीढ़ी के साथ स्पष्ट रूप से परिभाषित किया गया है।
प्रतिक्रियाशील प्रोग्रामिंग में कार्यान्वयन की चुनौतियाँ
अस्तव्यस्तता
परिवर्तनों का प्रचार करते समय, प्रचार आदेश चुनना संभव है | जैसे अभिव्यक्ति का मूल्य स्रोत प्रोग्राम का प्राकृतिक परिणाम नहीं है। इसे हम उदाहरण से सरलता से समझ सकते हैं। कल्पना करना seconds प्रतिक्रियाशील मान है जो वर्तमान समय (सेकेंड में) का प्रतिनिधित्व करने के लिए प्रत्येक सेकंड बदलता है। इस अभिव्यक्ति पर विचार करें |
t = seconds + 1
g = (t > seconds)
क्योंकि t से seconds, सदैव बड़ा होना चाहिए | इस अभिव्यक्ति का मूल्यांकन सदैव सही मान पर होना चाहिए। यह मूल्यांकन के क्रम पर निर्भर कर सकता है। जब seconds परिवर्तन, दो भावों को अपडेट करना है | seconds + 1 और सशर्त यदि पहला दूसरे से पहले मूल्यांकन करता है, तो यह अपरिवर्तनीय होगा। यदि, चूँकि, सशर्त अपडेट पहले, के पुराने मान का उपयोग करते हुए t और seconds का नया मूल्य , तब व्यंजक का मूल्यांकन गलत मान पर होगा। इसे अस्तव्यस्तता कहते हैं।
कुछ प्रतिक्रियाशील भाषाएँ अस्तव्यस्त-मुक्त हैं, और इस गुण को सिद्ध करती हैं | यह सामान्यतः टोपोलॉजिकल सॉर्टिंग एक्सप्रेशंस और टोपोलॉजिकल ऑर्डर में अपडेटिंग वैल्यू द्वारा हासिल किया जाता है। चूँकि, इसके प्रदर्शन निहितार्थ हो सकते हैं, जैसे मूल्यों के वितरण में देरी (प्रसार के क्रम के कारण)। इसलिए, कुछ स्थितियों में, प्रतिक्रियाशील भाषाएँ अस्तव्यस्तता की अनुमति देती हैं, और डेवलपर्स को इस संभावना के बारे में पता होना चाहिए कि मान अस्थायी रूप से प्रोग्राम स्रोत के अनुरूप होने में विफल हो सकते हैं, और यह कि कुछ अभिव्यक्तियाँ कई बार मूल्यांकन कर सकती हैं |(उदाहरण के लिए, t > seconds दो बार मूल्यांकन कर सकते हैं | एक बार जब का नया मान seconds आता है, और एक बार फिर कब t अपडेट) होता है।
चक्रीय निर्भरता
निर्भरता की सामयिक छँटाई निर्भरता ग्राफ पर निर्भर करती है | जो निर्देशित विश्वकोश ग्राफ (डीएजी) है। व्यवहार में, प्रोग्राम निर्भरता ग्राफ को परिभाषित कर सकता है | जिसमें चक्र होते हैं। सामान्यतः, प्रतिक्रियाशील प्रोग्रामिंग भाषाएं उम्मीद करती हैं कि प्रतिक्रियात्मक अपडेट को समाप्त करने की अनुमति देने के लिए कुछ तत्वों को पीछे के किनारे पर रखकर ऐसे चक्रों को तोड़ा जा सकता है। सामान्यतः, भाषाएं ऑपरेटर प्रदान करती हैं | जैसे delay इस उद्देश्य के लिए अपडेट तंत्र द्वारा उपयोग किया जाता है | क्योंकि a delay तात्पर्य यह है कि अगली बार चरण में क्या मूल्यांकन किया जाना चाहिए (वर्तमान मूल्यांकन को समाप्त करने की अनुमति)।
परिवर्तनशील अवस्था के साथ सहभागिता
प्रतिक्रियाशील भाषाएँ सामान्यतः मानती हैं कि उनके भाव शुद्ध कार्य हैं। यह अपडेट तंत्र को अपडेट करने के लिए अलग-अलग ऑर्डर चुनने की अनुमति देता है, और विशिष्ट आदेश को अनिर्दिष्ट छोड़ देता है |(जिससे अनुकूलन सक्षम होता है)। जब प्रतिक्रियाशील भाषा स्तर के साथ प्रोग्रामिंग भाषा में एम्बेड की जाती है | चूँकि, प्रोग्रामर के लिए उत्परिवर्तनीय संचालन करना संभव हो सकता है। इस अंतःक्रिया को सुगम कैसे बनाया जाए यह खुली समस्या बनी हुई है।
कुछ स्थितियों में सैद्धांतिक आंशिक समाधान संभव है। ऐसे दो समाधानों में सम्मिलित हैं:
- भाषा उत्परिवर्तनीय कोशिका की धारणा प्रस्तुत कर सकती है। परिवर्तनशील सेल वह है जिसके बारे में प्रतिक्रियाशील अपडेट प्रणाली को पता होता है | जिससे कि सेल में किए गए परिवर्तन बाकी प्रतिक्रियाशील प्रोग्राम में फैल जाते हैं। यह प्रोग्राम के गैर-प्रतिक्रियाशील भाग को पारंपरिक उत्परिवर्तन करने में सक्षम बनाता है | जबकि प्रतिक्रियाशील कोड को इस अपडेट के बारे में जागरूक होने और प्रतिक्रिया देने में सक्षम बनाता है | इस प्रकार प्रोग्राम में मूल्यों के बीच संबंधों की निरंतरता बनाए रखता है। ऐसी सेल प्रदान करने वाली प्रतिक्रियाशील भाषा का उदाहरण फ्रटाइम है।[2]
- उचित रूप से एनकैप्सुलेटेड ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी स्तर की एनकैप्सुलेटेड धारणा प्रस्तुत करती है। सिद्धांत रूप में, इस तरह के पुस्तकालय के लिए किसी भाषा के प्रतिक्रियाशील भाग के साथ सुचारू रूप से चलाना करना संभव है। उदाहरण के लिए, स्तर परिवर्तनों के बारे में प्रतिक्रियाशील अपडेट इंजन को सूचित करने के लिए ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी के गेटर्स में कॉलबैक स्थापित किए जा सकते हैं, और प्रतिक्रियाशील घटक में परिवर्तन गेटर्स के माध्यम से ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी में धकेले जा सकते हैं। फ्रटाइम ऐसी रणनीति अपनाता है।[3]
निर्भरता के ग्राफ का गतिशील अपडेट
कुछ प्रतिक्रियाशील भाषाओं में, निर्भरता का ग्राफ स्थिर होता है, अर्थात, प्रोग्राम के निष्पादन के समय ग्राफ स्थिर रहता है। अन्य भाषाओं में, ग्राफ़ गतिशील हो सकता है, अर्थात यह प्रोग्राम के निष्पादन के रूप में बदल सकता है। साधारण उदाहरण के लिए, इस उदाहरण पर विचार करें (जहाँ seconds प्रतिक्रियाशील मूल्य है)
t =
if ((seconds mod 2) == 0):
seconds + 1
else:
seconds - 1
end
t + 1प्रत्येक सेकेंड, इस अभिव्यक्ति का मूल्य अलग प्रतिक्रियाशील अभिव्यक्ति में बदल जाता है | जो t + 1 तो निर्भर करता है। इसलिए, निर्भरता का ग्राफ प्रत्येक सेकंड अपडेट होता है।
निर्भरता के गतिशील अपडेट की अनुमति देने से महत्वपूर्ण अभिव्यंजक शक्ति मिलती है (उदाहरण के लिए, ग्राफिकल यूज़र इंटरफ़ेस (जीयूआई) प्रोग्रामो में गतिशील निर्भरता नियमित रूप से होती है)। चूँकि, प्रतिक्रियाशील अपडेट इंजन को यह तय करना होगा कि क्या प्रत्येक बार अभिव्यक्ति का पुनर्निर्माण करना है, या अभिव्यक्ति के नोड को निर्मित किन्तु निष्क्रिय रखना है | बाद वाले स्थिति में, सुनिश्चित करें कि वे गणना में भाग नहीं लेते हैं | जब उन्हें सक्रिय नहीं माना जाता है।
अवधारणाएं
स्पष्टता की डिग्री
रिएक्टिव प्रोग्रामिंग भाषा बहुत स्पष्ट लोगों से लेकर हो सकती हैं | जहां तीरों का उपयोग करके डेटा प्रवाह स्थापित किया जाता है | जहां डेटा प्रवाह उन भाषा निर्माणों से प्राप्त होता है | जो अनिवार्य या कार्यात्मक प्रोग्रामिंग के समान दिखते हैं। उदाहरण के लिए, अनुमानित रूप से उठाए गए कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) में फ़ंक्शन कॉल डेटा प्रवाह ग्राफ़ में नोड का निर्माण करने के लिए अंतर्निहित रूप से कारण हो सकता है। गतिशील भाषाओं के लिए प्रतिक्रियाशील प्रोग्रामिंग लाइब्रेरी (जैसे कि लिस्प सेल और पायथन ट्रेलिस लाइब्रेरी) फ़ंक्शन के निष्पादन के समय पढ़े गए मानों के रनटाइम विश्लेषण से निर्भरता ग्राफ का निर्माण कर सकते हैं | डेटा प्रवाह विनिर्देशों को निहित और गतिशील दोनों होने की अनुमति देते हैं।
कभी-कभी रिएक्टिव प्रोग्रामिंग शब्द सॉफ्टवेयर इंजीनियरिंग के आर्किटेक्चर स्तर को संदर्भित करता है | जहां डेटा प्रवाह ग्राफ में अलग-अलग नोड सामान्य प्रोग्राम होते हैं | जो एक दूसरे के साथ संवाद करते हैं।
स्थिर या गतिशील
प्रतिक्रियाशील प्रोग्रामिंग विशुद्ध रूप से स्थिर हो सकती है | जहां डेटा प्रवाह स्थिर रूप से सेट किया जाता है, या गतिशील हो सकता है | जहां प्रोग्राम के निष्पादन के समय डेटा प्रवाह बदल सकता है।
डेटा फ़्लो ग्राफ़ में डेटा स्विच का उपयोग कुछ सीमा तक स्थिर डेटा फ्लो ग्राफ़ को गतिशील के रूप में प्रकट कर सकता है, और अंतर को थोड़ा धुंधला कर सकता है। सही प्रतिक्रियाशील प्रोग्रामिंग चूँकि डेटा प्रवाह ग्राफ के पुनर्निर्माण के लिए अनिवार्य प्रोग्रामिंग का उपयोग कर सकती है।
उच्च क्रम प्रतिक्रियाशील प्रोग्रामिंग
प्रतिक्रियाशील प्रोग्रामिंग को उच्च क्रम का कहा जा सकता है | यदि यह इस विचार का समर्थन करता है कि डेटा प्रवाह का उपयोग अन्य डेटा प्रवाह के निर्माण के लिए किया जा सकता है। अर्थात्, डेटा प्रवाह से परिणामी मान अन्य डेटा प्रवाह ग्राफ़ है | जिसे पहले के समान मूल्यांकन मॉडल का उपयोग करके निष्पादित किया जाता है।
डेटा प्रवाह विभेदीकरण
आदर्श रूप से सभी डेटा परिवर्तनों को तुरंत प्रचारित किया जाता है | किन्तु व्यवहार में यह सुनिश्चित नहीं किया जा सकता है। इसके अतिरिक्त डेटा प्रवाह ग्राफ़ के विभिन्न भागों को अलग-अलग मूल्यांकन प्राथमिकताएँ देना आवश्यक हो सकता है। इसे विभेदित प्रतिक्रियाशील प्रोग्रामिंग कहा जा सकता है ।[4]
उदाहरण के लिए, वर्ड प्रोसेसर में स्पेलिंग एरर की मार्किंग आवश्यक नहीं कि अक्षरों को डालने के साथ पूरी तरह से सिंक हो। यहाँ विभेदित प्रतिक्रियाशील प्रोग्रामिंग का उपयोग संभावित रूप से वर्तनी परीक्षक को कम प्राथमिकता देने के लिए किया जा सकता है | जिससे अन्य डेटा-प्रवाहों को तात्कालिक रखते हुए इसे विलंबित किया जा सकता है।
चूँकि, इस तरह की भिन्नता अतिरिक्त रचना जटिलता का परिचय देती है। उदाहरण के लिए, यह तय करना कि विभिन्न डेटा प्रवाह क्षेत्रों को कैसे परिभाषित किया जाए और विभिन्न डेटा प्रवाह क्षेत्रों के बीच होने वाली घटनाओं को कैसे संभालना है।
प्रतिक्रियाशील प्रोग्रामिंग के मूल्यांकन मॉडल
प्रतिक्रियाशील प्रोग्रामो का मूल्यांकन आवश्यक नहीं है कि स्टैक आधारित प्रोग्रामिंग भाषाओं का मूल्यांकन कैसे किया जाता है। इसके अतिरिक्त, जब कुछ डेटा को बदला जाता है, तो परिवर्तन को उन सभी डेटा में प्रचारित किया जाता है | जो बदले गए डेटा से आंशिक रूप से या पूरी तरह से प्राप्त होते हैं । यह परिवर्तन प्रसार कई विधियों से प्राप्त किया जा सकता है | जहाँ संभवतः सबसे स्वाभाविक विधि अमान्य/मंद-पुनर्वैधीकरण योजना है।
यदि डेटा संरचना का निश्चित आकार है, तो संभावित घातीय अपडेट जटिलता के कारण, स्टैक का उपयोग करके केवल सरलता से परिवर्तन का प्रचार करना समस्याग्रस्त हो सकता है। इस तरह के आकार को दोहराए गए हीरे के आकार के रूप में वर्णित किया जा सकता है, और इसकी संरचना निम्न है |
An→Bn→An+1, An→Cn→An+1, जहाँ n=1,2... इस समस्या को अमान्यता का प्रचार करके ही दूर किया जा सकता है | जब कुछ डेटा पहले से ही अमान्य नहीं है, और बाद में मंद मूल्यांकन का उपयोग करके आवश्यक होने पर डेटा को फिर से मान्य करें।
प्रतिक्रियाशील प्रोग्रामिंग के लिए अंतर्निहित समस्या यह है कि सामान्य प्रोग्रामिंग भाषा में मूल्यांकन और भूल जाने वाली अधिकांश संगणनाओं को डेटा-संरचनाओं के रूप में स्मृति में प्रदर्शित करने की आवश्यकता होती है। यह संभावित रूप से प्रतिक्रियाशील प्रोग्रामिंग को अत्यधिक मेमोरी खपत कर सकता है। चूँकि, जिसे कम करना कहा जाता है | जिस पर शोध इस समस्या को संभावित रूप से दूर कर सकता है।[5]
दूसरी तरफ, प्रतिक्रियाशील प्रोग्रामिंग ऐसा रूप है जिसे स्पष्ट समांतरता के रूप में वर्णित किया जा सकता है, और इसलिए समानांतर हार्डवेयर की शक्ति का उपयोग करने के लिए फायदेमंद हो सकता है।
प्रेक्षक प्रतिरूप के साथ समानताएं
रिएक्टिव प्रोग्रामिंग में सामान्यतः ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में उपयोग किए जाने वाले ऑब्जर्वर प्रतिरूप के साथ प्रमुख समानताएं होती हैं। चूँकि, डेटा प्रवाह अवधारणाओं को प्रोग्रामिंग भाषा में एकीकृत करने से उन्हें व्यक्त करना सरल हो जाएगा और इसलिए डेटा प्रवाह ग्राफ़ की ग्रैन्युलैरिटी बढ़ सकती है। उदाहरण के लिए, पर्यवेक्षक प्रतिरूप सामान्यतः संपूर्ण वस्तुओं/वर्गों के बीच डेटा-प्रवाह का वर्णन करता है | जबकि ऑब्जेक्ट-ओरिएंटेड प्रतिक्रियाशील प्रोग्रामिंग वस्तुओं/वर्गों के सदस्यों को लक्षित कर सकता है।
दृष्टिकोण
अनिवार्य
सामान्य अनिवार्य प्रोग्रामिंग के साथ प्रतिक्रियाशील प्रोग्रामिंग को फ्यूज करना संभव है। ऐसे प्रतिमान में अनिवार्य प्रोग्राम प्रतिक्रियाशील डेटा संरचनाओं पर काम करते हैं।[6] ऐसा सेट-अप कंस्ट्रेंट प्रोग्रामिंग के अनुरूप है | चूँकि, अनिवार्य बाधा प्रोग्रामिंग द्विदिश डेटा-प्रवाह बाधाओं का प्रबंधन करती है | अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग एक तरफ़ा डेटा-प्रवाह बाधाओं का प्रबंधन करती है।
ऑब्जेक्ट-ओरिएंटेड
ऑब्जेक्ट-ओरिएंटेड रिएक्टिव प्रोग्रामिंग (ओओआरपी) और रिएक्टिव प्रोग्रामिंग का संयोजन है। संभवतः इस तरह के संयोजन को बनाने का सबसे स्वाभाविक विधि इस प्रकार है | विधियों और क्षेत्रों के अतिरिक्त, वस्तुओं में ऐसी प्रतिक्रियाएँ होती हैं | जो स्वचालित रूप से पुनर्मूल्यांकन करती हैं | जब वे अन्य प्रतिक्रियाओं पर निर्भर करती हैं | जिन्हें संशोधित किया गया है।
यदि ओओआरपी भाषा अपनी अनिवार्य विधियों को बनाए रखती है, तो यह अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग की श्रेणी में भी आएगी।
कार्यात्मक
कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) कार्यात्मक प्रोग्रामिंग पर प्रतिक्रियाशील प्रोग्रामिंग के लिए प्रोग्रामिंग प्रतिमान है।
एक्टर आधारित
अभिनेताओं को प्रतिक्रियाशील प्रणालियों को रचना करने का प्रस्ताव दिया गया है | अधिकांशतः कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग के संयोजन में वितरित प्रतिक्रियाशील प्रणालियों को विकसित करने के लिए कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) और प्रतिक्रियाशील धाराएँ है।[7][8][9][10]
नियम आधारित
प्रोग्रामिंग भाषाओं की अपेक्षाकृत नई श्रेणी मुख्य प्रोग्रामिंग अवधारणा के रूप में बाधाओं (नियमों) का उपयोग करती है। इसमें घटनाओं की प्रतिक्रियाएँ होती हैं | जो सभी बाधाओं को संतुष्ट करती हैं। यह न केवल घटना-आधारित प्रतिक्रियाओं को सुविधाजनक बनाता है | किन्तु यह प्रतिक्रियाशील प्रोग्रामो को सॉफ्टवेयर की शुद्धता के लिए महत्वपूर्ण बनाता है। नियम आधारित प्रतिक्रियाशील प्रोग्रामिंग भाषा का उदाहरण एम्परसेंड है | जो संबंध बीजगणित में स्थापित है।[11]
कार्यान्वयन
- रिएक्टिवएक्स, आरएक्सजेएस, आरएक्सजावा, आरएक्सनेट, आरएक्सपीवाई और आरएक्सस्विफ्ट सहित कई भाषा कार्यान्वयन के साथ स्ट्रीम, ऑब्जर्वेबल और ऑपरेटरों के साथ प्रतिक्रियाशील प्रोग्रामिंग को प्रयुक्त करने के लिए एपीआई होता है।
- एल्म (प्रोग्रामिंग भाषा) वेब यूजर इंटरफेस की प्रतिक्रियाशील रचना।
- रिएक्टिव स्ट्रीम, नॉन-ब्लॉकिंग बैकप्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए जेवीएम मानक
- अवलोकनीय संगणनाएँ, क्रॉस-प्लेटफ़ॉर्म .नेट कार्यान्वयन।
- स्वेल्ते, वैरिएंट जावास्क्रिप्ट सिंटैक्स के रूप में प्रतिक्रियाशीलता लाता है | जेएसएक्स (जावास्क्रिप्ट) की तरह दिखता है | किन्तु स्वाभाविक रूप से प्रतिक्रियाशील होता है | जहाँ जावास्क्रिप्ट सामान्य रूप से नहीं होता है।
- सॉलिड.js, प्रतिक्रियाशील जेएसएक्स (जावास्क्रिप्ट) टेम्प्लेटिंग के साथ जावास्क्रिप्ट सिंटैक्स सिमेंटिक्स को बदले बिना जावास्क्रिप्ट में प्रतिक्रियाशीलता लाता है।
यह भी देखें
- ऑब्जर्वेबल (कम्प्यूटिंग), रिएक्टिव प्रोग्रामिंग में ऑब्जर्वेबल।
संदर्भ
- ↑ Trellis, Model-view-controller and the observer pattern, Tele community.
- ↑ "कॉल-बाय-वैल्यू लैंग्वेज में डायनेमिक डेटाफ्लो एम्बेड करना". cs.brown.edu. Retrieved 2016-10-09.
- ↑ "Crossing State Lines: Adapting Object-Oriented Frameworks to Functional Reactive Languages". cs.brown.edu. Retrieved 2016-10-09.
- ↑ "Reactive Programming – The Art of Service | The IT Management Guide". theartofservice.com. Retrieved 2016-07-02.
- ↑ Burchett, Kimberley; Cooper, Gregory H; Krishnamurthi, Shriram, "Lowering: a static optimization technique for transparent functional reactivity", Proceedings of the 2007 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation (PDF), pp. 71–80.
- ↑ Demetrescu, Camil; Finocchi, Irene; Ribichini, Andrea (22 October 2011), "Reactive Imperative Programming with Dataflow Constraints", Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications, Oopsla '11, pp. 407–26, doi:10.1145/2048066.2048100, ISBN 9781450309400, S2CID 7285961.
- ↑ Van den Vonder, Sam; Renaux, Thierry; Oeyen, Bjarno; De Koster, Joeri; De Meuter, Wolfgang (2020), "Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model", Leibniz International Proceedings in Informatics (LIPIcs), vol. 166, pp. 19:1–19:29, doi:10.4230/LIPIcs.ECOOP.2020.19, ISBN 9783959771542.
- ↑ Van den Vonder, Sam; Renaux, Thierry; De Meuter, Wolfgang (2022), "Topology-Level Reactivity in Distributed Reactive Programs: Reactive Acquaintance Management using Flocks", The Art, Science, and Engineering of Programming, vol. 6:3, pp. 14:1–14:36, doi:10.22152/programming-journal.org/2022/6/14
- ↑ Shibanai, Kazuhiro; Watanabe, Takuo (2018), "Distributed Functional Reactive Programming on Actor-Based Runtime", Proceedings of the 8th ACM SIGPLAN International Workshop on Programming Based on Actors, Agents, and Decentralized Control, Agere 2018, pp. 13–22, doi:10.1145/3281366.3281370, ISBN 9781450360661, S2CID 53113447
- ↑ Roestenburg, Raymond; Bakker, Rob; Williams, Rob (2016). "13: Streaming". क्रिया के रूप में. Greenwich, Connecticut, USA: Manning Publications Co. p. 281. ISBN 978-1-61729-101-2.
- ↑ Joosten, Stef (2018), "Relation Algebra as programming language using the Ampersand compiler", Journal of Logical and Algebraic Methods in Programming, vol. 100, pp. 113–29, doi:10.1016/j.jlamp.2018.04.002, S2CID 52932824.
बाहरी संबंध
- A survey on reactive programming A 2013 paper by E. Bainomugisha, A. Lombide Carreton, T. Van Cutsem, S. Mostinckx, and W. De Meuter that surveys and provides a taxonomy of existing reactive programming approaches.
- MIMOSA Project of INRIA - ENSMP, a general site about reactive programming.
- Deprecating the Observer Pattern A 2010 paper by Ingo Maier, Tiark Rompf and Martin Odersky outlining a reactive programming framework for the Scala programming language.
- Deprecating the Observer Pattern with Scala.React A 2012 paper by Ingo
- RxJS, the Reactive Extensions library for "composing asynchronous [...] programs using observable sequences"
- Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model A 2020 paper that proposes a model of "actors" and "reactors" to avoid the issues that arise when combining imperative code with reactive code.
