रिएक्टिव प्रोग्रामिंग: Difference between revisions
No edit summary |
No edit summary |
||
| 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> के वर्तमान में आवंटित मूल्य का निर्धारण करने के लिए <code>a</code>. | ||
''' | '''अन्य उदाहरण [[हार्डवेयर विवरण भाषा]] है जैसे कि [[Verilog]], जहां सर्किट के माध्यम से प्रचार करते हैं।''' | ||
{{sxhl|2=javascript|1= | {{sxhl|2=javascript|1= | ||
var b = 1 | var b = 1 | ||
| Line 21: | Line 21: | ||
}} | }} | ||
एक अन्य उदाहरण | एक अन्य उदाहरण [[हार्डवेयर विवरण भाषा]] है जैसे कि [[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> | ||
== प्रतिक्रियाशील प्रोग्रामिंग भाषाएँ बनाने के लिए दृष्टिकोण == | == प्रतिक्रियाशील प्रोग्रामिंग भाषाएँ बनाने के लिए दृष्टिकोण == | ||
प्रतिक्रियाशील प्रोग्रामिंग भाषाओं के निर्माण में कई लोकप्रिय दृष्टिकोण कार्यरत हैं। समर्पित भाषाओं की विशिष्टता जो विभिन्न डोमेन बाधाओं के लिए विशिष्ट हैं। ऐसी बाधाओं को आमतौर पर रीयल-टाइम, एम्बेडेड कंप्यूटिंग या हार्डवेयर विवरण द्वारा वर्णित किया जाता है। एक अन्य दृष्टिकोण में सामान्य-उद्देश्य वाली भाषाओं के विनिर्देश शामिल हैं जिनमें प्रतिक्रियाशीलता के लिए समर्थन शामिल है। अन्य दृष्टिकोणों को परिभाषा में व्यक्त किया गया है, और प्रोग्रामिंग पुस्तकालयों, या एम्बेडेड [[डोमेन-विशिष्ट भाषा]]ओं का उपयोग, जो प्रोग्रामिंग भाषा के साथ या शीर्ष पर प्रतिक्रियाशीलता को सक्षम करता है। विशिष्टता और इन विभिन्न दृष्टिकोणों के उपयोग के परिणामस्वरूप भाषा क्षमता व्यापार-नापसंद हो जाती है। सामान्य तौर पर, | प्रतिक्रियाशील प्रोग्रामिंग भाषाओं के निर्माण में कई लोकप्रिय दृष्टिकोण कार्यरत हैं। समर्पित भाषाओं की विशिष्टता जो विभिन्न डोमेन बाधाओं के लिए विशिष्ट हैं। ऐसी बाधाओं को आमतौर पर रीयल-टाइम, एम्बेडेड कंप्यूटिंग या हार्डवेयर विवरण द्वारा वर्णित किया जाता है। एक अन्य दृष्टिकोण में सामान्य-उद्देश्य वाली भाषाओं के विनिर्देश शामिल हैं जिनमें प्रतिक्रियाशीलता के लिए समर्थन शामिल है। अन्य दृष्टिकोणों को परिभाषा में व्यक्त किया गया है, और प्रोग्रामिंग पुस्तकालयों, या एम्बेडेड [[डोमेन-विशिष्ट भाषा]]ओं का उपयोग, जो प्रोग्रामिंग भाषा के साथ या शीर्ष पर प्रतिक्रियाशीलता को सक्षम करता है। विशिष्टता और इन विभिन्न दृष्टिकोणों के उपयोग के परिणामस्वरूप भाषा क्षमता व्यापार-नापसंद हो जाती है। सामान्य तौर पर, भाषा जितनी अधिक प्रतिबंधित होती है, उससे जुड़े संकलक और विश्लेषण उपकरण डेवलपर्स को सूचित करने में सक्षम होते हैं (उदाहरण के लिए, वास्तविक वास्तविक समय में कार्यक्रम निष्पादित करने में सक्षम हैं या नहीं, इसके लिए विश्लेषण करने में)। विशिष्टता में कार्यात्मक व्यापार-नापसंद का परिणाम किसी भाषा की सामान्य प्रयोज्यता में गिरावट हो सकता है। | ||
== प्रोग्रामिंग मॉडल और शब्दार्थ == | == प्रोग्रामिंग मॉडल और शब्दार्थ == | ||
| Line 44: | Line 44: | ||
=== कार्यान्वयन का सार === | === कार्यान्वयन का सार === | ||
प्रतिक्रियाशील प्रोग्रामिंग भाषा रनटाइम को | प्रतिक्रियाशील प्रोग्रामिंग भाषा रनटाइम को ग्राफ़ द्वारा दर्शाया जाता है जो शामिल प्रतिक्रियाशील मूल्यों के बीच निर्भरता की पहचान करता है। इस तरह के ग्राफ में, नोड्स कंप्यूटिंग और किनारों के मॉडल निर्भरता संबंधों के कार्य का प्रतिनिधित्व करते हैं। इस तरह के रनटाइम ने उक्त ग्राफ को नियोजित किया है, जिससे यह विभिन्न संगणनाओं पर नज़र रखने में मदद करता है, जिसे नए सिरे से निष्पादित किया जाना चाहिए, एक बार इसमें शामिल इनपुट मान बदल जाता है। | ||
==== प्रचार एल्गोरिदम बदलें ==== | ==== प्रचार एल्गोरिदम बदलें ==== | ||
| Line 52: | Line 52: | ||
* खींचो: मूल्य उपभोक्ता वास्तव में 'सक्रिय' है, जिसमें यह नियमित रूप से मूल्यों के लिए देखे गए स्रोत से पूछताछ करता है और जब भी कोई प्रासंगिक मूल्य उपलब्ध होता है तो प्रतिक्रिया करता है। घटनाओं या मूल्य परिवर्तनों के लिए नियमित रूप से जाँच करने के इस अभ्यास को आमतौर पर ''पोलिंग'' कहा जाता है। | * खींचो: मूल्य उपभोक्ता वास्तव में 'सक्रिय' है, जिसमें यह नियमित रूप से मूल्यों के लिए देखे गए स्रोत से पूछताछ करता है और जब भी कोई प्रासंगिक मूल्य उपलब्ध होता है तो प्रतिक्रिया करता है। घटनाओं या मूल्य परिवर्तनों के लिए नियमित रूप से जाँच करने के इस अभ्यास को आमतौर पर ''पोलिंग'' कहा जाता है। | ||
* पुश: जब भी मूल्य उपलब्ध हो जाता है तो मूल्य उपभोक्ता स्रोत से मूल्य प्राप्त करता है। ये मूल्य स्व-निहित हैं, उदा। उनमें सभी आवश्यक जानकारी होती है, और उपभोक्ता द्वारा और कोई जानकारी पूछने की आवश्यकता नहीं होती है। | * पुश: जब भी मूल्य उपलब्ध हो जाता है तो मूल्य उपभोक्ता स्रोत से मूल्य प्राप्त करता है। ये मूल्य स्व-निहित हैं, उदा। उनमें सभी आवश्यक जानकारी होती है, और उपभोक्ता द्वारा और कोई जानकारी पूछने की आवश्यकता नहीं होती है। | ||
* पुश-पुल: मूल्य उपभोक्ता को | * पुश-पुल: मूल्य उपभोक्ता को ''परिवर्तन सूचना'' प्राप्त होती है, जो परिवर्तन का संक्षिप्त विवरण है, उदा. कुछ मूल्य बदल गए - यह 'पुश' भाग है। हालाँकि, अधिसूचना में सभी आवश्यक जानकारी नहीं होती है (जिसका अर्थ है कि इसमें वास्तविक मान शामिल नहीं हैं), इसलिए उपभोक्ता को अधिसूचना प्राप्त होने के बाद अधिक जानकारी (विशिष्ट मूल्य) के लिए स्रोत से पूछताछ करने की आवश्यकता है - यह '' है खींचो' भाग. इस पद्धति का आमतौर पर उपयोग तब किया जाता है जब बड़ी मात्रा में डेटा होता है जिसमें उपभोक्ताओं की संभावित रुचि हो सकती है। इसलिए थ्रूपुट और विलंबता को कम करने के लिए, केवल हल्के-फुल्के नोटिफिकेशन भेजे जाते हैं; और फिर जिन उपभोक्ताओं को अधिक जानकारी की आवश्यकता है, वे उस विशिष्ट जानकारी का अनुरोध करेंगे। इस दृष्टिकोण में यह दोष भी है कि सूचना भेजे जाने के बाद स्रोत अतिरिक्त जानकारी के लिए कई अनुरोधों से अभिभूत हो सकता है। | ||
==== क्या धक्का देना है? ==== | ==== क्या धक्का देना है? ==== | ||
कार्यान्वयन स्तर पर, घटना की प्रतिक्रिया में | कार्यान्वयन स्तर पर, घटना की प्रतिक्रिया में ग्राफ की जानकारी में प्रसार होता है, जो परिवर्तन के अस्तित्व को दर्शाता है। नतीजतन, ऐसे परिवर्तन से प्रभावित होने वाली संगणनाएं पुरानी हो जाती हैं और उन्हें फिर से निष्पादन के लिए फ़्लैग किया जाना चाहिए। इस तरह की संगणनाओं को आमतौर पर इसके संबद्ध स्रोत में परिवर्तन के [[सकर्मक बंद]] होने की विशेषता होती है। प्रसार परिवर्तन से ग्राफ़ के सिंक के मान में अद्यतन हो सकता है। | ||
ग्राफ़ प्रचारित जानकारी में नोड की पूर्ण स्थिति शामिल हो सकती है, अर्थात, शामिल नोड का संगणना परिणाम। ऐसे मामलों में, नोड के पिछले आउटपुट को तब अनदेखा कर दिया जाता है। एक अन्य विधि में डेल्टा प्रचार यानी वृद्धिशील परिवर्तन प्रसार शामिल है। इस मामले में, सूचना को ग्राफ के किनारों के साथ फैलाया जाता है, जिसमें केवल डेल्टा होते हैं जो बताते हैं कि पिछले नोड को कैसे बदला गया था। यह दृष्टिकोण विशेष रूप से महत्वपूर्ण है जब नोड्स बड़ी मात्रा में राज्य डेटा रखते हैं, जो अन्यथा खरोंच से पुनर्गणना करना महंगा होगा। | ग्राफ़ प्रचारित जानकारी में नोड की पूर्ण स्थिति शामिल हो सकती है, अर्थात, शामिल नोड का संगणना परिणाम। ऐसे मामलों में, नोड के पिछले आउटपुट को तब अनदेखा कर दिया जाता है। एक अन्य विधि में डेल्टा प्रचार यानी वृद्धिशील परिवर्तन प्रसार शामिल है। इस मामले में, सूचना को ग्राफ के किनारों के साथ फैलाया जाता है, जिसमें केवल डेल्टा होते हैं जो बताते हैं कि पिछले नोड को कैसे बदला गया था। यह दृष्टिकोण विशेष रूप से महत्वपूर्ण है जब नोड्स बड़ी मात्रा में राज्य डेटा रखते हैं, जो अन्यथा खरोंच से पुनर्गणना करना महंगा होगा। | ||
डेल्टा प्रसार अनिवार्य रूप से | डेल्टा प्रसार अनिवार्य रूप से अनुकूलन है जिसे [[वृद्धिशील कंप्यूटिंग]] के अनुशासन के माध्यम से बड़े पैमाने पर अध्ययन किया गया है, जिसके दृष्टिकोण में [[डेटाबेस]]#External.2C वैचारिक.2C और आंतरिक विचारों|दृश्य-अद्यतन समस्या को शामिल करते हुए रनटाइम संतुष्टि की आवश्यकता होती है। यह समस्या डेटाबेस संस्थाओं के उपयोग के लिए बदनाम है, जो बदलते डेटा दृश्यों के रखरखाव के लिए जिम्मेदार हैं। | ||
एक अन्य सामान्य अनुकूलन एकात्मक परिवर्तन संचय और बैच प्रसार का रोजगार है। ऐसा समाधान तेजी से हो सकता है क्योंकि यह शामिल नोड्स के बीच संचार को कम करता है। अनुकूलन रणनीतियों को तब नियोजित किया जा सकता है जो भीतर निहित परिवर्तनों की प्रकृति के बारे में तर्क देते हैं और तदनुसार परिवर्तन करते हैं। उदा. बैच में दो परिवर्तन एक दूसरे को रद्द कर सकते हैं, और इस प्रकार, केवल अनदेखा किया जा सकता है। फिर भी एक और उपलब्ध दृष्टिकोण, अमान्यता अधिसूचना प्रचार के रूप में वर्णित है। यह दृष्टिकोण अद्यतनों को खींचने के लिए अमान्य इनपुट वाले नोड्स का कारण बनता है, इस प्रकार परिणामस्वरूप अपने स्वयं के आउटपुट का अद्यतन होता है। | एक अन्य सामान्य अनुकूलन एकात्मक परिवर्तन संचय और बैच प्रसार का रोजगार है। ऐसा समाधान तेजी से हो सकता है क्योंकि यह शामिल नोड्स के बीच संचार को कम करता है। अनुकूलन रणनीतियों को तब नियोजित किया जा सकता है जो भीतर निहित परिवर्तनों की प्रकृति के बारे में तर्क देते हैं और तदनुसार परिवर्तन करते हैं। उदा. बैच में दो परिवर्तन एक दूसरे को रद्द कर सकते हैं, और इस प्रकार, केवल अनदेखा किया जा सकता है। फिर भी एक और उपलब्ध दृष्टिकोण, अमान्यता अधिसूचना प्रचार के रूप में वर्णित है। यह दृष्टिकोण अद्यतनों को खींचने के लिए अमान्य इनपुट वाले नोड्स का कारण बनता है, इस प्रकार परिणामस्वरूप अपने स्वयं के आउटपुट का अद्यतन होता है। | ||
[[निर्भरता ग्राफ]] के निर्माण में नियोजित दो प्रमुख तरीके हैं: | [[निर्भरता ग्राफ]] के निर्माण में नियोजित दो प्रमुख तरीके हैं: | ||
# निर्भरता का ग्राफ | # निर्भरता का ग्राफ घटना लूप के भीतर निहित रूप से बनाए रखा जाता है। स्पष्ट कॉलबैक का पंजीकरण, जिसके परिणामस्वरूप अंतर्निहित निर्भरताओं का निर्माण होता है। इसलिए, नियंत्रण उलटा, जो कॉलबैक के माध्यम से प्रेरित होता है, इस प्रकार छोड़ दिया जाता है। हालाँकि, कॉलबैक को कार्यात्मक बनाना (अर्थात इकाई मूल्य के बजाय राज्य मूल्य लौटाना) आवश्यक है कि इस तरह के कॉलबैक संरचनागत हों। | ||
# निर्भरता का | # निर्भरता का ग्राफ प्रोग्राम-विशिष्ट है और प्रोग्रामर द्वारा उत्पन्न किया गया है। यह कॉलबैक के नियंत्रण व्युत्क्रम को दो तरीकों से संबोधित करने की सुविधा प्रदान करता है: या तो ग्राफ स्पष्ट रूप से निर्दिष्ट किया जाता है (आमतौर पर डोमेन-विशिष्ट भाषा (डीएसएल) का उपयोग करके, जिसे एम्बेड किया जा सकता है), या ग्राफ को प्रभावी का उपयोग करके अभिव्यक्ति और पीढ़ी के साथ स्पष्ट रूप से परिभाषित किया गया है। , कट्टर भाषा। | ||
=== प्रतिक्रियाशील प्रोग्रामिंग === में कार्यान्वयन की चुनौतियाँ | === प्रतिक्रियाशील प्रोग्रामिंग === में कार्यान्वयन की चुनौतियाँ | ||
| Line 72: | Line 72: | ||
==== गड़बड़ियां ==== | ==== गड़बड़ियां ==== | ||
परिवर्तनों का प्रचार करते समय, प्रचार आदेश चुनना संभव है जैसे अभिव्यक्ति का मूल्य स्रोत कार्यक्रम का प्राकृतिक परिणाम नहीं है। इसे हम | परिवर्तनों का प्रचार करते समय, प्रचार आदेश चुनना संभव है जैसे अभिव्यक्ति का मूल्य स्रोत कार्यक्रम का प्राकृतिक परिणाम नहीं है। इसे हम उदाहरण से आसानी से समझ सकते हैं। कल्पना करना <code>seconds</code> प्रतिक्रियाशील मान है जो वर्तमान समय (सेकेंड में) का प्रतिनिधित्व करने के लिए हर सेकंड बदलता है। इस अभिव्यक्ति पर विचार करें: | ||
<पूर्व> | <पूर्व> | ||
| Line 79: | Line 79: | ||
</पूर्व> | </पूर्व> | ||
[[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>, तब व्यंजक का मूल्यांकन | [[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>t > seconds</code> दो बार मूल्यांकन कर सकते हैं: एक बार जब का नया मान <code>seconds</code> आता है, और एक बार फिर कब <code>t</code> अपडेट)। | ||
| Line 85: | Line 85: | ||
==== चक्रीय निर्भरता ==== | ==== चक्रीय निर्भरता ==== | ||
निर्भरता की सामयिक छँटाई निर्भरता ग्राफ पर निर्भर करती है जो | निर्भरता की सामयिक छँटाई निर्भरता ग्राफ पर निर्भर करती है जो निर्देशित विश्वकोश ग्राफ (DAG) है। व्यवहार में, प्रोग्राम निर्भरता ग्राफ को परिभाषित कर सकता है जिसमें चक्र होते हैं। आमतौर पर, प्रतिक्रियाशील प्रोग्रामिंग भाषाएं उम्मीद करती हैं कि प्रतिक्रियात्मक अद्यतन को समाप्त करने की अनुमति देने के लिए कुछ तत्वों को पीछे के किनारे पर रखकर ऐसे चक्रों को तोड़ा जा सकता है। आमतौर पर, भाषाएं ऑपरेटर प्रदान करती हैं जैसे <code>delay</code> इस उद्देश्य के लिए अद्यतन तंत्र द्वारा उपयोग किया जाता है, क्योंकि a <code>delay</code> तात्पर्य यह है कि अगली बार चरण में क्या मूल्यांकन किया जाना चाहिए (वर्तमान मूल्यांकन को समाप्त करने की अनुमति)। | ||
==== परिवर्तनशील अवस्था के साथ सहभागिता ==== | ==== परिवर्तनशील अवस्था के साथ सहभागिता ==== | ||
प्रतिक्रियाशील भाषाएँ आमतौर पर मानती हैं कि उनके भाव शुद्ध कार्य हैं। यह | प्रतिक्रियाशील भाषाएँ आमतौर पर मानती हैं कि उनके भाव शुद्ध कार्य हैं। यह अद्यतन तंत्र को अद्यतन करने के लिए अलग-अलग ऑर्डर चुनने की अनुमति देता है, और विशिष्ट आदेश को अनिर्दिष्ट छोड़ देता है (जिससे अनुकूलन सक्षम होता है)। जब प्रतिक्रियाशील भाषा राज्य के साथ प्रोग्रामिंग भाषा में एम्बेड की जाती है, हालांकि, प्रोग्रामर के लिए उत्परिवर्तनीय संचालन करना संभव हो सकता है। इस अंतःक्रिया को सुगम कैसे बनाया जाए यह खुली समस्या बनी हुई है। | ||
कुछ मामलों में सैद्धांतिक आंशिक समाधान संभव है। ऐसे दो समाधानों में शामिल हैं: | कुछ मामलों में सैद्धांतिक आंशिक समाधान संभव है। ऐसे दो समाधानों में शामिल हैं: | ||
* | * भाषा उत्परिवर्तनीय कोशिका की धारणा पेश कर सकती है। परिवर्तनशील सेल वह है जिसके बारे में प्रतिक्रियाशील अद्यतन प्रणाली को पता होता है, जिससे कि सेल में किए गए परिवर्तन बाकी प्रतिक्रियाशील प्रोग्राम में फैल जाते हैं। यह कार्यक्रम के गैर-प्रतिक्रियाशील हिस्से को पारंपरिक उत्परिवर्तन करने में सक्षम बनाता है, जबकि प्रतिक्रियाशील कोड को इस अद्यतन के बारे में जागरूक होने और प्रतिक्रिया देने में सक्षम बनाता है, इस प्रकार कार्यक्रम में मूल्यों के बीच संबंधों की निरंतरता बनाए रखता है। ऐसी सेल प्रदान करने वाली प्रतिक्रियाशील भाषा का उदाहरण FrTime है।<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> | ||
* उचित रूप से एनकैप्सुलेटेड ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी राज्य की | * उचित रूप से एनकैप्सुलेटेड ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी राज्य की एनकैप्सुलेटेड धारणा पेश करती है। सिद्धांत रूप में, इस तरह के पुस्तकालय के लिए किसी भाषा के प्रतिक्रियाशील भाग के साथ सुचारू रूप से बातचीत करना संभव है। उदाहरण के लिए, राज्य परिवर्तनों के बारे में प्रतिक्रियाशील अद्यतन इंजन को सूचित करने के लिए ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी के गेटर्स में कॉलबैक स्थापित किए जा सकते हैं, और प्रतिक्रियाशील घटक में परिवर्तन गेटर्स के माध्यम से ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी में धकेले जा सकते हैं। FrTime ऐसी रणनीति अपनाता है।<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> प्रतिक्रियाशील मूल्य है): | ||
<पूर्व> | <पूर्व> | ||
टी = | टी = | ||
| Line 109: | Line 109: | ||
टी + 1 | टी + 1 | ||
</पूर्व> | </पूर्व> | ||
प्रत्येक सेकेंड, इस अभिव्यक्ति का मूल्य | प्रत्येक सेकेंड, इस अभिव्यक्ति का मूल्य अलग प्रतिक्रियाशील अभिव्यक्ति में बदल जाता है, जो <code>t + 1</code> तो निर्भर करता है। इसलिए, निर्भरता का ग्राफ हर सेकंड अपडेट होता है। | ||
निर्भरता के गतिशील अद्यतन की अनुमति देने से महत्वपूर्ण अभिव्यंजक शक्ति मिलती है (उदाहरण के लिए, [[ ग्राफिकल यूज़र इंटरफ़ेस ]] (जीयूआई) कार्यक्रमों में गतिशील निर्भरता नियमित रूप से होती है)। हालाँकि, प्रतिक्रियाशील अद्यतन इंजन को यह तय करना होगा कि क्या हर बार अभिव्यक्ति का पुनर्निर्माण करना है, या अभिव्यक्ति के नोड को निर्मित लेकिन निष्क्रिय रखना है; बाद वाले मामले में, सुनिश्चित करें कि वे गणना में भाग नहीं लेते हैं जब उन्हें सक्रिय नहीं माना जाता है। | निर्भरता के गतिशील अद्यतन की अनुमति देने से महत्वपूर्ण अभिव्यंजक शक्ति मिलती है (उदाहरण के लिए, [[ ग्राफिकल यूज़र इंटरफ़ेस ]] (जीयूआई) कार्यक्रमों में गतिशील निर्भरता नियमित रूप से होती है)। हालाँकि, प्रतिक्रियाशील अद्यतन इंजन को यह तय करना होगा कि क्या हर बार अभिव्यक्ति का पुनर्निर्माण करना है, या अभिव्यक्ति के नोड को निर्मित लेकिन निष्क्रिय रखना है; बाद वाले मामले में, सुनिश्चित करें कि वे गणना में भाग नहीं लेते हैं जब उन्हें सक्रिय नहीं माना जाता है। | ||
| Line 116: | Line 116: | ||
=== स्पष्टता की डिग्री === | === स्पष्टता की डिग्री === | ||
रिएक्टिव प्रोग्रामिंग लैंग्वेज बहुत स्पष्ट लोगों से लेकर हो सकती हैं, जहां तीरों का उपयोग करके डेटा प्रवाह स्थापित किया जाता है, जहां डेटा प्रवाह उन भाषा निर्माणों से प्राप्त होता है, जो अनिवार्य या कार्यात्मक प्रोग्रामिंग के समान दिखते हैं। उदाहरण के लिए, अनुमानित रूप से उठाए गए [[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] (एफआरपी) में | रिएक्टिव प्रोग्रामिंग लैंग्वेज बहुत स्पष्ट लोगों से लेकर हो सकती हैं, जहां तीरों का उपयोग करके डेटा प्रवाह स्थापित किया जाता है, जहां डेटा प्रवाह उन भाषा निर्माणों से प्राप्त होता है, जो अनिवार्य या कार्यात्मक प्रोग्रामिंग के समान दिखते हैं। उदाहरण के लिए, अनुमानित रूप से उठाए गए [[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] (एफआरपी) में फ़ंक्शन कॉल डेटा प्रवाह ग्राफ़ में नोड का निर्माण करने के लिए अंतर्निहित रूप से कारण हो सकता है। गतिशील भाषाओं के लिए प्रतिक्रियाशील प्रोग्रामिंग लाइब्रेरी (जैसे कि लिस्प सेल और पायथन ट्रेलिस लाइब्रेरी) फ़ंक्शन के निष्पादन के दौरान पढ़े गए मानों के रनटाइम विश्लेषण से निर्भरता ग्राफ का निर्माण कर सकते हैं, डेटा प्रवाह विनिर्देशों को निहित और गतिशील दोनों होने की अनुमति देते हैं। | ||
कभी-कभी रिएक्टिव प्रोग्रामिंग शब्द सॉफ्टवेयर इंजीनियरिंग के वास्तुशिल्प स्तर को संदर्भित करता है, जहां डेटा प्रवाह ग्राफ में अलग-अलग नोड सामान्य प्रोग्राम होते हैं जो एक दूसरे के साथ संवाद करते हैं। | कभी-कभी रिएक्टिव प्रोग्रामिंग शब्द सॉफ्टवेयर इंजीनियरिंग के वास्तुशिल्प स्तर को संदर्भित करता है, जहां डेटा प्रवाह ग्राफ में अलग-अलग नोड सामान्य प्रोग्राम होते हैं जो एक दूसरे के साथ संवाद करते हैं। | ||
| Line 123: | Line 123: | ||
प्रतिक्रियाशील प्रोग्रामिंग विशुद्ध रूप से स्थिर हो सकती है जहां डेटा प्रवाह स्थिर रूप से सेट किया जाता है, या गतिशील हो सकता है जहां प्रोग्राम के निष्पादन के दौरान डेटा प्रवाह बदल सकता है। | प्रतिक्रियाशील प्रोग्रामिंग विशुद्ध रूप से स्थिर हो सकती है जहां डेटा प्रवाह स्थिर रूप से सेट किया जाता है, या गतिशील हो सकता है जहां प्रोग्राम के निष्पादन के दौरान डेटा प्रवाह बदल सकता है। | ||
डेटा फ़्लो ग्राफ़ में डेटा स्विच का उपयोग कुछ हद तक | डेटा फ़्लो ग्राफ़ में डेटा स्विच का उपयोग कुछ हद तक स्थिर डेटा फ्लो ग्राफ़ को गतिशील के रूप में प्रकट कर सकता है, और अंतर को थोड़ा धुंधला कर सकता है। सही गतिशील प्रतिक्रियाशील प्रोग्रामिंग हालांकि डेटा प्रवाह ग्राफ के पुनर्निर्माण के लिए अनिवार्य प्रोग्रामिंग का उपयोग कर सकती है। | ||
=== उच्च क्रम प्रतिक्रियाशील प्रोग्रामिंग === | === उच्च क्रम प्रतिक्रियाशील प्रोग्रामिंग === | ||
प्रतिक्रियाशील प्रोग्रामिंग को उच्च क्रम का कहा जा सकता है यदि यह इस विचार का समर्थन करता है कि डेटा प्रवाह का उपयोग अन्य डेटा प्रवाह के निर्माण के लिए किया जा सकता है। अर्थात्, डेटा प्रवाह से परिणामी मान | प्रतिक्रियाशील प्रोग्रामिंग को उच्च क्रम का कहा जा सकता है यदि यह इस विचार का समर्थन करता है कि डेटा प्रवाह का उपयोग अन्य डेटा प्रवाह के निर्माण के लिए किया जा सकता है। अर्थात्, डेटा प्रवाह से परिणामी मान अन्य डेटा प्रवाह ग्राफ़ है जिसे पहले के समान मूल्यांकन मॉडल का उपयोग करके निष्पादित किया जाता है। | ||
=== डेटा प्रवाह भेदभाव === | === डेटा प्रवाह भेदभाव === | ||
| Line 135: | Line 135: | ||
=== प्रतिक्रियाशील प्रोग्रामिंग के मूल्यांकन मॉडल === | === प्रतिक्रियाशील प्रोग्रामिंग के मूल्यांकन मॉडल === | ||
प्रतिक्रियाशील कार्यक्रमों का मूल्यांकन जरूरी नहीं है कि स्टैक आधारित प्रोग्रामिंग भाषाओं का मूल्यांकन कैसे किया जाता है। इसके बजाय, जब कुछ डेटा को बदला जाता है, तो परिवर्तन को उन सभी डेटा में प्रचारित किया जाता है जो बदले गए डेटा से आंशिक रूप से या पूरी तरह से प्राप्त होते हैं। यह परिवर्तन प्रसार कई तरीकों से प्राप्त किया जा सकता है, जहाँ शायद सबसे स्वाभाविक तरीका | प्रतिक्रियाशील कार्यक्रमों का मूल्यांकन जरूरी नहीं है कि स्टैक आधारित प्रोग्रामिंग भाषाओं का मूल्यांकन कैसे किया जाता है। इसके बजाय, जब कुछ डेटा को बदला जाता है, तो परिवर्तन को उन सभी डेटा में प्रचारित किया जाता है जो बदले गए डेटा से आंशिक रूप से या पूरी तरह से प्राप्त होते हैं। यह परिवर्तन प्रसार कई तरीकों से प्राप्त किया जा सकता है, जहाँ शायद सबसे स्वाभाविक तरीका अमान्य/आलसी-पुनर्वैधीकरण योजना है। | ||
यदि डेटा संरचना का | यदि डेटा संरचना का निश्चित आकार है, तो संभावित घातीय अद्यतन जटिलता के कारण, स्टैक का उपयोग करके केवल भोलेपन से परिवर्तन का प्रचार करना समस्याग्रस्त हो सकता है। इस तरह के आकार को दोहराए गए हीरे के आकार के रूप में वर्णित किया जा सकता है, और इसकी संरचना निम्न है: | ||
ए<sub>n</sub>→B<sub>n</sub>→A<sub>n+1</sub>, ए<sub>n</sub>→C<sub>n</sub>→A<sub>n+1</sub>, जहाँ n=1,2... इस समस्या को अमान्यता का प्रचार करके ही दूर किया जा सकता है जब कुछ डेटा पहले से ही अमान्य नहीं है, और बाद में [[आलसी मूल्यांकन]] का उपयोग करके आवश्यक होने पर डेटा को फिर से मान्य करें। | ए<sub>n</sub>→B<sub>n</sub>→A<sub>n+1</sub>, ए<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> | ||
दूसरी तरफ, प्रतिक्रियाशील प्रोग्रामिंग | दूसरी तरफ, प्रतिक्रियाशील प्रोग्रामिंग ऐसा रूप है जिसे स्पष्ट समांतरता के रूप में वर्णित किया जा सकता है, और इसलिए समानांतर हार्डवेयर की शक्ति का उपयोग करने के लिए फायदेमंद हो सकता है। | ||
==== प्रेक्षक पैटर्न के साथ समानताएं ==== | ==== प्रेक्षक पैटर्न के साथ समानताएं ==== | ||
| Line 152: | Line 152: | ||
=== वस्तु-उन्मुख === | === वस्तु-उन्मुख === | ||
ऑब्जेक्ट-ओरिएंटेड रिएक्टिव प्रोग्रामिंग (ओओआरपी) ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग और रिएक्टिव प्रोग्रामिंग का | ऑब्जेक्ट-ओरिएंटेड रिएक्टिव प्रोग्रामिंग (ओओआरपी) ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग और रिएक्टिव प्रोग्रामिंग का संयोजन है। शायद इस तरह के संयोजन को बनाने का सबसे स्वाभाविक तरीका इस प्रकार है: विधियों और क्षेत्रों के बजाय, वस्तुओं में ऐसी प्रतिक्रियाएँ होती हैं जो स्वचालित रूप से पुनर्मूल्यांकन करती हैं जब वे अन्य प्रतिक्रियाओं पर निर्भर करती हैं जिन्हें संशोधित किया गया है।{{Citation needed|date= December 2012}} | ||
यदि | यदि OORP भाषा अपनी अनिवार्य विधियों को बनाए रखती है, तो यह अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग की श्रेणी में भी आएगी। | ||
=== कार्यात्मक === | === कार्यात्मक === | ||
[[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] | कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) [[कार्यात्मक प्रोग्रामिंग]] पर प्रतिक्रियाशील प्रोग्रामिंग के लिए | [[कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग]] | कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) [[कार्यात्मक प्रोग्रामिंग]] पर प्रतिक्रियाशील प्रोग्रामिंग के लिए प्रोग्रामिंग प्रतिमान है। | ||
=== अभिनेता आधारित === | === अभिनेता आधारित === | ||
| Line 164: | Line 164: | ||
=== नियम आधारित === | === नियम आधारित === | ||
प्रोग्रामिंग भाषाओं की | प्रोग्रामिंग भाषाओं की अपेक्षाकृत नई श्रेणी मुख्य प्रोग्रामिंग अवधारणा के रूप में बाधाओं (नियमों) का उपयोग करती है। इसमें घटनाओं की प्रतिक्रियाएँ होती हैं, जो सभी बाधाओं को संतुष्ट करती हैं। यह न केवल घटना-आधारित प्रतिक्रियाओं को सुविधाजनक बनाता है, बल्कि यह प्रतिक्रियाशील कार्यक्रमों को सॉफ्टवेयर की शुद्धता के लिए महत्वपूर्ण बनाता है। नियम आधारित प्रतिक्रियाशील प्रोग्रामिंग भाषा का उदाहरण एम्परसेंड है, जो [[संबंध बीजगणित]] में स्थापित है।<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]], RxJs, RxJava, Rx.NET, RxPy और RxSwift सहित कई भाषा कार्यान्वयन के साथ स्ट्रीम, ऑब्जर्वेबल और ऑपरेटरों के साथ प्रतिक्रियाशील प्रोग्रामिंग को लागू करने के लिए | * [[ReactiveX]], RxJs, RxJava, Rx.NET, RxPy और RxSwift सहित कई भाषा कार्यान्वयन के साथ स्ट्रीम, ऑब्जर्वेबल और ऑपरेटरों के साथ प्रतिक्रियाशील प्रोग्रामिंग को लागू करने के लिए एपीआई। | ||
* [[एल्म (प्रोग्रामिंग भाषा)]] वेब यूजर इंटरफेस की प्रतिक्रियाशील रचना। | * [[एल्म (प्रोग्रामिंग भाषा)]] वेब यूजर इंटरफेस की प्रतिक्रियाशील रचना। | ||
* रिएक्टिव स्ट्रीम, नॉन-ब्लॉकिंग बैकप्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए | * रिएक्टिव स्ट्रीम, नॉन-ब्लॉकिंग बैकप्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए जेवीएम मानक | ||
* [https://github.com/IgorBuchelnikov/ObservableComputations ObservableComputations], | * [https://github.com/IgorBuchelnikov/ObservableComputations ObservableComputations], क्रॉस-प्लेटफ़ॉर्म .NET कार्यान्वयन। | ||
* [[Svelte]], | * [[Svelte]], वैरिएंट [[जावास्क्रिप्ट]] सिंटैक्स के रूप में प्रतिक्रियाशीलता लाता है [[जेएसएक्स (जावास्क्रिप्ट)]] की तरह दिखता है लेकिन स्वाभाविक रूप से प्रतिक्रियाशील होता है जहाँ जावास्क्रिप्ट सामान्य रूप से नहीं होता है। | ||
* [https://solidjs.com/ Solid.js], प्रतिक्रियाशील JSX (जावास्क्रिप्ट) टेम्प्लेटिंग के साथ [[जावास्क्रिप्ट सिंटैक्स]] सिमेंटिक्स को बदले बिना जावास्क्रिप्ट में प्रतिक्रियाशीलता लाता है। | * [https://solidjs.com/ Solid.js], प्रतिक्रियाशील JSX (जावास्क्रिप्ट) टेम्प्लेटिंग के साथ [[जावास्क्रिप्ट सिंटैक्स]] सिमेंटिक्स को बदले बिना जावास्क्रिप्ट में प्रतिक्रियाशीलता लाता है। | ||
Revision as of 13:28, 19 May 2023
कम्प्यूटिंग में, प्रतिक्रियाशील प्रोग्रामिंग स्ट्रीम (कंप्यूटिंग) और परिवर्तन के प्रसार से संबंधित घोषणात्मक प्रोग्रामिंग प्रोग्रामिंग प्रतिमान है। इस प्रतिमान के साथ, स्थैतिक (जैसे, सरणियाँ) या गतिशील (जैसे, घटना उत्सर्जक) डेटा स्ट्रीम को आसानी से व्यक्त करना संभव है, और यह भी संप्रेषित करता है कि संबद्ध निष्पादन मॉडल के भीतर अनुमानित निर्भरता मौजूद है, जो बदले हुए डेटा के स्वत: प्रसार की सुविधा प्रदान करता है। प्रवाह।
उदाहरण के लिए, अनिवार्य प्रोग्रामिंग सेटिंग में, a := b + c इसका मतलब होगा a का परिणाम सौंपा जा रहा है b + c तत्काल अभिव्यक्ति का मूल्यांकन किया जाता है, और बाद में, के मान b और c के मूल्य पर बिना किसी प्रभाव के बदला जा सकता है a. दूसरी ओर, प्रतिक्रियाशील प्रोग्रामिंग में, का मूल्य a जब भी के मान स्वचालित रूप से अपडेट हो जाते हैं b या c परिवर्तन, कार्यक्रम के बिना बयान को स्पष्ट रूप से फिर से निष्पादित करने के लिए a := b + c के वर्तमान में आवंटित मूल्य का निर्धारण करने के लिए a.
अन्य उदाहरण हार्डवेयर विवरण भाषा है जैसे कि Verilog, जहां सर्किट के माध्यम से प्रचार करते हैं।
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
एक अन्य उदाहरण हार्डवेयर विवरण भाषा है जैसे कि Verilog, जहां प्रतिक्रियाशील प्रोग्रामिंग परिवर्तनों को मॉडलिंग करने में सक्षम बनाती है क्योंकि वे सर्किट के माध्यम से प्रचार करते हैं।
प्रतिक्रियाशील प्रोग्रामिंग को इंटरैक्टिव यूजर इंटरफेस और निकट-वास्तविक समय सिस्टम एनीमेशन के निर्माण को आसान बनाने के तरीके के रूप में प्रस्तावित किया गया है।
उदाहरण के लिए, मॉडल-व्यू-कंट्रोलर (एमवीसी) आर्किटेक्चर में, प्रतिक्रियाशील प्रोग्रामिंग अंतर्निहित मॉडल में परिवर्तन की सुविधा प्रदान कर सकती है जो संबंधित दृश्य में स्वचालित रूप से परिलक्षित होती है।[1]
प्रतिक्रियाशील प्रोग्रामिंग भाषाएँ बनाने के लिए दृष्टिकोण
प्रतिक्रियाशील प्रोग्रामिंग भाषाओं के निर्माण में कई लोकप्रिय दृष्टिकोण कार्यरत हैं। समर्पित भाषाओं की विशिष्टता जो विभिन्न डोमेन बाधाओं के लिए विशिष्ट हैं। ऐसी बाधाओं को आमतौर पर रीयल-टाइम, एम्बेडेड कंप्यूटिंग या हार्डवेयर विवरण द्वारा वर्णित किया जाता है। एक अन्य दृष्टिकोण में सामान्य-उद्देश्य वाली भाषाओं के विनिर्देश शामिल हैं जिनमें प्रतिक्रियाशीलता के लिए समर्थन शामिल है। अन्य दृष्टिकोणों को परिभाषा में व्यक्त किया गया है, और प्रोग्रामिंग पुस्तकालयों, या एम्बेडेड डोमेन-विशिष्ट भाषाओं का उपयोग, जो प्रोग्रामिंग भाषा के साथ या शीर्ष पर प्रतिक्रियाशीलता को सक्षम करता है। विशिष्टता और इन विभिन्न दृष्टिकोणों के उपयोग के परिणामस्वरूप भाषा क्षमता व्यापार-नापसंद हो जाती है। सामान्य तौर पर, भाषा जितनी अधिक प्रतिबंधित होती है, उससे जुड़े संकलक और विश्लेषण उपकरण डेवलपर्स को सूचित करने में सक्षम होते हैं (उदाहरण के लिए, वास्तविक वास्तविक समय में कार्यक्रम निष्पादित करने में सक्षम हैं या नहीं, इसके लिए विश्लेषण करने में)। विशिष्टता में कार्यात्मक व्यापार-नापसंद का परिणाम किसी भाषा की सामान्य प्रयोज्यता में गिरावट हो सकता है।
प्रोग्रामिंग मॉडल और शब्दार्थ
विभिन्न प्रकार के मॉडल और शब्दार्थ प्रतिक्रियाशील प्रोग्रामिंग को नियंत्रित करते हैं। हम उन्हें निम्नलिखित आयामों में शिथिल रूप से विभाजित कर सकते हैं:
- तुल्यकालिक: समय का तुल्यकालिक बनाम अतुल्यकालिक मॉडल
- नियतत्ववाद: नियतात्मक बनाम गैर-नियतात्मक मूल्यांकन प्रक्रिया और परिणाम
- अद्यतन प्रक्रिया: कॉलबैक (कंप्यूटर प्रोग्रामिंग) बनाम डेटाफ्लो बनाम अभिनेता
कार्यान्वयन तकनीकें और चुनौतियाँ
कार्यान्वयन का सार
प्रतिक्रियाशील प्रोग्रामिंग भाषा रनटाइम को ग्राफ़ द्वारा दर्शाया जाता है जो शामिल प्रतिक्रियाशील मूल्यों के बीच निर्भरता की पहचान करता है। इस तरह के ग्राफ में, नोड्स कंप्यूटिंग और किनारों के मॉडल निर्भरता संबंधों के कार्य का प्रतिनिधित्व करते हैं। इस तरह के रनटाइम ने उक्त ग्राफ को नियोजित किया है, जिससे यह विभिन्न संगणनाओं पर नज़र रखने में मदद करता है, जिसे नए सिरे से निष्पादित किया जाना चाहिए, एक बार इसमें शामिल इनपुट मान बदल जाता है।
प्रचार एल्गोरिदम बदलें
डेटा प्रसार के सबसे आम तरीके हैं:
- खींचो: मूल्य उपभोक्ता वास्तव में 'सक्रिय' है, जिसमें यह नियमित रूप से मूल्यों के लिए देखे गए स्रोत से पूछताछ करता है और जब भी कोई प्रासंगिक मूल्य उपलब्ध होता है तो प्रतिक्रिया करता है। घटनाओं या मूल्य परिवर्तनों के लिए नियमित रूप से जाँच करने के इस अभ्यास को आमतौर पर पोलिंग कहा जाता है।
- पुश: जब भी मूल्य उपलब्ध हो जाता है तो मूल्य उपभोक्ता स्रोत से मूल्य प्राप्त करता है। ये मूल्य स्व-निहित हैं, उदा। उनमें सभी आवश्यक जानकारी होती है, और उपभोक्ता द्वारा और कोई जानकारी पूछने की आवश्यकता नहीं होती है।
- पुश-पुल: मूल्य उपभोक्ता को परिवर्तन सूचना प्राप्त होती है, जो परिवर्तन का संक्षिप्त विवरण है, उदा. कुछ मूल्य बदल गए - यह 'पुश' भाग है। हालाँकि, अधिसूचना में सभी आवश्यक जानकारी नहीं होती है (जिसका अर्थ है कि इसमें वास्तविक मान शामिल नहीं हैं), इसलिए उपभोक्ता को अधिसूचना प्राप्त होने के बाद अधिक जानकारी (विशिष्ट मूल्य) के लिए स्रोत से पूछताछ करने की आवश्यकता है - यह है खींचो' भाग. इस पद्धति का आमतौर पर उपयोग तब किया जाता है जब बड़ी मात्रा में डेटा होता है जिसमें उपभोक्ताओं की संभावित रुचि हो सकती है। इसलिए थ्रूपुट और विलंबता को कम करने के लिए, केवल हल्के-फुल्के नोटिफिकेशन भेजे जाते हैं; और फिर जिन उपभोक्ताओं को अधिक जानकारी की आवश्यकता है, वे उस विशिष्ट जानकारी का अनुरोध करेंगे। इस दृष्टिकोण में यह दोष भी है कि सूचना भेजे जाने के बाद स्रोत अतिरिक्त जानकारी के लिए कई अनुरोधों से अभिभूत हो सकता है।
क्या धक्का देना है?
कार्यान्वयन स्तर पर, घटना की प्रतिक्रिया में ग्राफ की जानकारी में प्रसार होता है, जो परिवर्तन के अस्तित्व को दर्शाता है। नतीजतन, ऐसे परिवर्तन से प्रभावित होने वाली संगणनाएं पुरानी हो जाती हैं और उन्हें फिर से निष्पादन के लिए फ़्लैग किया जाना चाहिए। इस तरह की संगणनाओं को आमतौर पर इसके संबद्ध स्रोत में परिवर्तन के सकर्मक बंद होने की विशेषता होती है। प्रसार परिवर्तन से ग्राफ़ के सिंक के मान में अद्यतन हो सकता है।
ग्राफ़ प्रचारित जानकारी में नोड की पूर्ण स्थिति शामिल हो सकती है, अर्थात, शामिल नोड का संगणना परिणाम। ऐसे मामलों में, नोड के पिछले आउटपुट को तब अनदेखा कर दिया जाता है। एक अन्य विधि में डेल्टा प्रचार यानी वृद्धिशील परिवर्तन प्रसार शामिल है। इस मामले में, सूचना को ग्राफ के किनारों के साथ फैलाया जाता है, जिसमें केवल डेल्टा होते हैं जो बताते हैं कि पिछले नोड को कैसे बदला गया था। यह दृष्टिकोण विशेष रूप से महत्वपूर्ण है जब नोड्स बड़ी मात्रा में राज्य डेटा रखते हैं, जो अन्यथा खरोंच से पुनर्गणना करना महंगा होगा।
डेल्टा प्रसार अनिवार्य रूप से अनुकूलन है जिसे वृद्धिशील कंप्यूटिंग के अनुशासन के माध्यम से बड़े पैमाने पर अध्ययन किया गया है, जिसके दृष्टिकोण में डेटाबेस#External.2C वैचारिक.2C और आंतरिक विचारों|दृश्य-अद्यतन समस्या को शामिल करते हुए रनटाइम संतुष्टि की आवश्यकता होती है। यह समस्या डेटाबेस संस्थाओं के उपयोग के लिए बदनाम है, जो बदलते डेटा दृश्यों के रखरखाव के लिए जिम्मेदार हैं।
एक अन्य सामान्य अनुकूलन एकात्मक परिवर्तन संचय और बैच प्रसार का रोजगार है। ऐसा समाधान तेजी से हो सकता है क्योंकि यह शामिल नोड्स के बीच संचार को कम करता है। अनुकूलन रणनीतियों को तब नियोजित किया जा सकता है जो भीतर निहित परिवर्तनों की प्रकृति के बारे में तर्क देते हैं और तदनुसार परिवर्तन करते हैं। उदा. बैच में दो परिवर्तन एक दूसरे को रद्द कर सकते हैं, और इस प्रकार, केवल अनदेखा किया जा सकता है। फिर भी एक और उपलब्ध दृष्टिकोण, अमान्यता अधिसूचना प्रचार के रूप में वर्णित है। यह दृष्टिकोण अद्यतनों को खींचने के लिए अमान्य इनपुट वाले नोड्स का कारण बनता है, इस प्रकार परिणामस्वरूप अपने स्वयं के आउटपुट का अद्यतन होता है।
निर्भरता ग्राफ के निर्माण में नियोजित दो प्रमुख तरीके हैं:
- निर्भरता का ग्राफ घटना लूप के भीतर निहित रूप से बनाए रखा जाता है। स्पष्ट कॉलबैक का पंजीकरण, जिसके परिणामस्वरूप अंतर्निहित निर्भरताओं का निर्माण होता है। इसलिए, नियंत्रण उलटा, जो कॉलबैक के माध्यम से प्रेरित होता है, इस प्रकार छोड़ दिया जाता है। हालाँकि, कॉलबैक को कार्यात्मक बनाना (अर्थात इकाई मूल्य के बजाय राज्य मूल्य लौटाना) आवश्यक है कि इस तरह के कॉलबैक संरचनागत हों।
- निर्भरता का ग्राफ प्रोग्राम-विशिष्ट है और प्रोग्रामर द्वारा उत्पन्न किया गया है। यह कॉलबैक के नियंत्रण व्युत्क्रम को दो तरीकों से संबोधित करने की सुविधा प्रदान करता है: या तो ग्राफ स्पष्ट रूप से निर्दिष्ट किया जाता है (आमतौर पर डोमेन-विशिष्ट भाषा (डीएसएल) का उपयोग करके, जिसे एम्बेड किया जा सकता है), या ग्राफ को प्रभावी का उपयोग करके अभिव्यक्ति और पीढ़ी के साथ स्पष्ट रूप से परिभाषित किया गया है। , कट्टर भाषा।
=== प्रतिक्रियाशील प्रोग्रामिंग === में कार्यान्वयन की चुनौतियाँ
गड़बड़ियां
परिवर्तनों का प्रचार करते समय, प्रचार आदेश चुनना संभव है जैसे अभिव्यक्ति का मूल्य स्रोत कार्यक्रम का प्राकृतिक परिणाम नहीं है। इसे हम उदाहरण से आसानी से समझ सकते हैं। कल्पना करना seconds प्रतिक्रियाशील मान है जो वर्तमान समय (सेकेंड में) का प्रतिनिधित्व करने के लिए हर सेकंड बदलता है। इस अभिव्यक्ति पर विचार करें:
<पूर्व> टी = सेकेंड + 1 जी = (टी> सेकेंड) </पूर्व>
क्योंकि t से हमेशा बड़ा होना चाहिए seconds, इस अभिव्यक्ति का मूल्यांकन हमेशा सही मान पर होना चाहिए। दुर्भाग्य से, यह मूल्यांकन के क्रम पर निर्भर कर सकता है। कब seconds परिवर्तन, दो भावों को अद्यतन करना है: seconds + 1 और सशर्त। यदि पहला दूसरे से पहले मूल्यांकन करता है, तो यह अपरिवर्तनीय होगा। यदि, हालांकि, सशर्त अद्यतन पहले, के पुराने मान का उपयोग करते हुए t और का नया मूल्य seconds, तब व्यंजक का मूल्यांकन गलत मान पर होगा। इसे गड़बड़ी कहते हैं।
कुछ प्रतिक्रियाशील भाषाएँ गड़बड़-मुक्त हैं, और इस गुण को सिद्ध करती हैं. यह आमतौर पर टोपोलॉजिकल सॉर्टिंग एक्सप्रेशंस और टोपोलॉजिकल ऑर्डर में अपडेटिंग वैल्यू द्वारा हासिल किया जाता है। हालाँकि, इसके प्रदर्शन निहितार्थ हो सकते हैं, जैसे मूल्यों के वितरण में देरी (प्रसार के क्रम के कारण)। इसलिए, कुछ मामलों में, प्रतिक्रियाशील भाषाएँ गड़बड़ियों की अनुमति देती हैं, और डेवलपर्स को इस संभावना के बारे में पता होना चाहिए कि मान अस्थायी रूप से प्रोग्राम स्रोत के अनुरूप होने में विफल हो सकते हैं, और यह कि कुछ अभिव्यक्तियाँ कई बार मूल्यांकन कर सकती हैं (उदाहरण के लिए, t > seconds दो बार मूल्यांकन कर सकते हैं: एक बार जब का नया मान seconds आता है, और एक बार फिर कब t अपडेट)।
चक्रीय निर्भरता
निर्भरता की सामयिक छँटाई निर्भरता ग्राफ पर निर्भर करती है जो निर्देशित विश्वकोश ग्राफ (DAG) है। व्यवहार में, प्रोग्राम निर्भरता ग्राफ को परिभाषित कर सकता है जिसमें चक्र होते हैं। आमतौर पर, प्रतिक्रियाशील प्रोग्रामिंग भाषाएं उम्मीद करती हैं कि प्रतिक्रियात्मक अद्यतन को समाप्त करने की अनुमति देने के लिए कुछ तत्वों को पीछे के किनारे पर रखकर ऐसे चक्रों को तोड़ा जा सकता है। आमतौर पर, भाषाएं ऑपरेटर प्रदान करती हैं जैसे delay इस उद्देश्य के लिए अद्यतन तंत्र द्वारा उपयोग किया जाता है, क्योंकि a delay तात्पर्य यह है कि अगली बार चरण में क्या मूल्यांकन किया जाना चाहिए (वर्तमान मूल्यांकन को समाप्त करने की अनुमति)।
परिवर्तनशील अवस्था के साथ सहभागिता
प्रतिक्रियाशील भाषाएँ आमतौर पर मानती हैं कि उनके भाव शुद्ध कार्य हैं। यह अद्यतन तंत्र को अद्यतन करने के लिए अलग-अलग ऑर्डर चुनने की अनुमति देता है, और विशिष्ट आदेश को अनिर्दिष्ट छोड़ देता है (जिससे अनुकूलन सक्षम होता है)। जब प्रतिक्रियाशील भाषा राज्य के साथ प्रोग्रामिंग भाषा में एम्बेड की जाती है, हालांकि, प्रोग्रामर के लिए उत्परिवर्तनीय संचालन करना संभव हो सकता है। इस अंतःक्रिया को सुगम कैसे बनाया जाए यह खुली समस्या बनी हुई है।
कुछ मामलों में सैद्धांतिक आंशिक समाधान संभव है। ऐसे दो समाधानों में शामिल हैं:
- भाषा उत्परिवर्तनीय कोशिका की धारणा पेश कर सकती है। परिवर्तनशील सेल वह है जिसके बारे में प्रतिक्रियाशील अद्यतन प्रणाली को पता होता है, जिससे कि सेल में किए गए परिवर्तन बाकी प्रतिक्रियाशील प्रोग्राम में फैल जाते हैं। यह कार्यक्रम के गैर-प्रतिक्रियाशील हिस्से को पारंपरिक उत्परिवर्तन करने में सक्षम बनाता है, जबकि प्रतिक्रियाशील कोड को इस अद्यतन के बारे में जागरूक होने और प्रतिक्रिया देने में सक्षम बनाता है, इस प्रकार कार्यक्रम में मूल्यों के बीच संबंधों की निरंतरता बनाए रखता है। ऐसी सेल प्रदान करने वाली प्रतिक्रियाशील भाषा का उदाहरण FrTime है।[2]
- उचित रूप से एनकैप्सुलेटेड ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी राज्य की एनकैप्सुलेटेड धारणा पेश करती है। सिद्धांत रूप में, इस तरह के पुस्तकालय के लिए किसी भाषा के प्रतिक्रियाशील भाग के साथ सुचारू रूप से बातचीत करना संभव है। उदाहरण के लिए, राज्य परिवर्तनों के बारे में प्रतिक्रियाशील अद्यतन इंजन को सूचित करने के लिए ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी के गेटर्स में कॉलबैक स्थापित किए जा सकते हैं, और प्रतिक्रियाशील घटक में परिवर्तन गेटर्स के माध्यम से ऑब्जेक्ट-ओरिएंटेड लाइब्रेरी में धकेले जा सकते हैं। FrTime ऐसी रणनीति अपनाता है।[3]
निर्भरता के ग्राफ का गतिशील अद्यतन
कुछ प्रतिक्रियाशील भाषाओं में, निर्भरता का ग्राफ स्थिर होता है, अर्थात, कार्यक्रम के निष्पादन के दौरान ग्राफ स्थिर रहता है। अन्य भाषाओं में, ग्राफ़ गतिशील हो सकता है, अर्थात यह प्रोग्राम के निष्पादन के रूप में बदल सकता है। साधारण उदाहरण के लिए, इस उदाहरण पर विचार करें (जहाँ seconds प्रतिक्रियाशील मूल्य है):
<पूर्व>
टी =
अगर ((सेकंड मॉड 2) == 0): सेकंड + 1 अन्य: सेकंड - 1 अंत
टी + 1
</पूर्व>
प्रत्येक सेकेंड, इस अभिव्यक्ति का मूल्य अलग प्रतिक्रियाशील अभिव्यक्ति में बदल जाता है, जो t + 1 तो निर्भर करता है। इसलिए, निर्भरता का ग्राफ हर सेकंड अपडेट होता है।
निर्भरता के गतिशील अद्यतन की अनुमति देने से महत्वपूर्ण अभिव्यंजक शक्ति मिलती है (उदाहरण के लिए, ग्राफिकल यूज़र इंटरफ़ेस (जीयूआई) कार्यक्रमों में गतिशील निर्भरता नियमित रूप से होती है)। हालाँकि, प्रतिक्रियाशील अद्यतन इंजन को यह तय करना होगा कि क्या हर बार अभिव्यक्ति का पुनर्निर्माण करना है, या अभिव्यक्ति के नोड को निर्मित लेकिन निष्क्रिय रखना है; बाद वाले मामले में, सुनिश्चित करें कि वे गणना में भाग नहीं लेते हैं जब उन्हें सक्रिय नहीं माना जाता है।
अवधारणाएं
स्पष्टता की डिग्री
रिएक्टिव प्रोग्रामिंग लैंग्वेज बहुत स्पष्ट लोगों से लेकर हो सकती हैं, जहां तीरों का उपयोग करके डेटा प्रवाह स्थापित किया जाता है, जहां डेटा प्रवाह उन भाषा निर्माणों से प्राप्त होता है, जो अनिवार्य या कार्यात्मक प्रोग्रामिंग के समान दिखते हैं। उदाहरण के लिए, अनुमानित रूप से उठाए गए कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) में फ़ंक्शन कॉल डेटा प्रवाह ग्राफ़ में नोड का निर्माण करने के लिए अंतर्निहित रूप से कारण हो सकता है। गतिशील भाषाओं के लिए प्रतिक्रियाशील प्रोग्रामिंग लाइब्रेरी (जैसे कि लिस्प सेल और पायथन ट्रेलिस लाइब्रेरी) फ़ंक्शन के निष्पादन के दौरान पढ़े गए मानों के रनटाइम विश्लेषण से निर्भरता ग्राफ का निर्माण कर सकते हैं, डेटा प्रवाह विनिर्देशों को निहित और गतिशील दोनों होने की अनुमति देते हैं।
कभी-कभी रिएक्टिव प्रोग्रामिंग शब्द सॉफ्टवेयर इंजीनियरिंग के वास्तुशिल्प स्तर को संदर्भित करता है, जहां डेटा प्रवाह ग्राफ में अलग-अलग नोड सामान्य प्रोग्राम होते हैं जो एक दूसरे के साथ संवाद करते हैं।
स्थिर या गतिशील
प्रतिक्रियाशील प्रोग्रामिंग विशुद्ध रूप से स्थिर हो सकती है जहां डेटा प्रवाह स्थिर रूप से सेट किया जाता है, या गतिशील हो सकता है जहां प्रोग्राम के निष्पादन के दौरान डेटा प्रवाह बदल सकता है।
डेटा फ़्लो ग्राफ़ में डेटा स्विच का उपयोग कुछ हद तक स्थिर डेटा फ्लो ग्राफ़ को गतिशील के रूप में प्रकट कर सकता है, और अंतर को थोड़ा धुंधला कर सकता है। सही गतिशील प्रतिक्रियाशील प्रोग्रामिंग हालांकि डेटा प्रवाह ग्राफ के पुनर्निर्माण के लिए अनिवार्य प्रोग्रामिंग का उपयोग कर सकती है।
उच्च क्रम प्रतिक्रियाशील प्रोग्रामिंग
प्रतिक्रियाशील प्रोग्रामिंग को उच्च क्रम का कहा जा सकता है यदि यह इस विचार का समर्थन करता है कि डेटा प्रवाह का उपयोग अन्य डेटा प्रवाह के निर्माण के लिए किया जा सकता है। अर्थात्, डेटा प्रवाह से परिणामी मान अन्य डेटा प्रवाह ग्राफ़ है जिसे पहले के समान मूल्यांकन मॉडल का उपयोग करके निष्पादित किया जाता है।
डेटा प्रवाह भेदभाव
आदर्श रूप से सभी डेटा परिवर्तनों को तुरंत प्रचारित किया जाता है, लेकिन व्यवहार में यह सुनिश्चित नहीं किया जा सकता है। इसके बजाय डेटा प्रवाह ग्राफ़ के विभिन्न भागों को अलग-अलग मूल्यांकन प्राथमिकताएँ देना आवश्यक हो सकता है। इसे विभेदित प्रतिक्रियाशील प्रोग्रामिंग कहा जा सकता है।[4] उदाहरण के लिए, वर्ड प्रोसेसर में स्पेलिंग एरर की मार्किंग जरूरी नहीं कि अक्षरों को डालने के साथ पूरी तरह से सिंक हो। यहाँ विभेदित प्रतिक्रियाशील प्रोग्रामिंग का उपयोग संभावित रूप से वर्तनी परीक्षक को कम प्राथमिकता देने के लिए किया जा सकता है, जिससे अन्य डेटा-प्रवाहों को तात्कालिक रखते हुए इसे विलंबित किया जा सकता है।
हालाँकि, इस तरह की भिन्नता अतिरिक्त डिज़ाइन जटिलता का परिचय देती है। उदाहरण के लिए, यह तय करना कि विभिन्न डेटा प्रवाह क्षेत्रों को कैसे परिभाषित किया जाए, और विभिन्न डेटा प्रवाह क्षेत्रों के बीच होने वाली घटनाओं को कैसे संभालना है।
प्रतिक्रियाशील प्रोग्रामिंग के मूल्यांकन मॉडल
प्रतिक्रियाशील कार्यक्रमों का मूल्यांकन जरूरी नहीं है कि स्टैक आधारित प्रोग्रामिंग भाषाओं का मूल्यांकन कैसे किया जाता है। इसके बजाय, जब कुछ डेटा को बदला जाता है, तो परिवर्तन को उन सभी डेटा में प्रचारित किया जाता है जो बदले गए डेटा से आंशिक रूप से या पूरी तरह से प्राप्त होते हैं। यह परिवर्तन प्रसार कई तरीकों से प्राप्त किया जा सकता है, जहाँ शायद सबसे स्वाभाविक तरीका अमान्य/आलसी-पुनर्वैधीकरण योजना है।
यदि डेटा संरचना का निश्चित आकार है, तो संभावित घातीय अद्यतन जटिलता के कारण, स्टैक का उपयोग करके केवल भोलेपन से परिवर्तन का प्रचार करना समस्याग्रस्त हो सकता है। इस तरह के आकार को दोहराए गए हीरे के आकार के रूप में वर्णित किया जा सकता है, और इसकी संरचना निम्न है: एn→Bn→An+1, एn→Cn→An+1, जहाँ n=1,2... इस समस्या को अमान्यता का प्रचार करके ही दूर किया जा सकता है जब कुछ डेटा पहले से ही अमान्य नहीं है, और बाद में आलसी मूल्यांकन का उपयोग करके आवश्यक होने पर डेटा को फिर से मान्य करें।
प्रतिक्रियाशील प्रोग्रामिंग के लिए अंतर्निहित समस्या यह है कि सामान्य प्रोग्रामिंग भाषा में मूल्यांकन और भूल जाने वाली अधिकांश संगणनाओं को डेटा-संरचनाओं के रूप में स्मृति में प्रदर्शित करने की आवश्यकता होती है। यह संभावित रूप से प्रतिक्रियाशील प्रोग्रामिंग को अत्यधिक मेमोरी खपत कर सकता है। हालाँकि, जिसे कम करना कहा जाता है, पर शोध इस समस्या को संभावित रूप से दूर कर सकता है।[5] दूसरी तरफ, प्रतिक्रियाशील प्रोग्रामिंग ऐसा रूप है जिसे स्पष्ट समांतरता के रूप में वर्णित किया जा सकता है, और इसलिए समानांतर हार्डवेयर की शक्ति का उपयोग करने के लिए फायदेमंद हो सकता है।
प्रेक्षक पैटर्न के साथ समानताएं
रिएक्टिव प्रोग्रामिंग में आमतौर पर ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में उपयोग किए जाने वाले ऑब्जर्वर पैटर्न के साथ प्रमुख समानताएं होती हैं। हालाँकि, डेटा प्रवाह अवधारणाओं को प्रोग्रामिंग भाषा में एकीकृत करने से उन्हें व्यक्त करना आसान हो जाएगा और इसलिए डेटा प्रवाह ग्राफ़ की ग्रैन्युलैरिटी बढ़ सकती है। उदाहरण के लिए, पर्यवेक्षक पैटर्न आमतौर पर संपूर्ण वस्तुओं/वर्गों के बीच डेटा-प्रवाह का वर्णन करता है, जबकि वस्तु-उन्मुख प्रतिक्रियाशील प्रोग्रामिंग वस्तुओं/वर्गों के सदस्यों को लक्षित कर सकता है।
दृष्टिकोण
अनिवार्य
सामान्य अनिवार्य प्रोग्रामिंग के साथ प्रतिक्रियाशील प्रोग्रामिंग को फ्यूज करना संभव है। ऐसे प्रतिमान में, अनिवार्य कार्यक्रम प्रतिक्रियाशील डेटा संरचनाओं पर काम करते हैं।[6] ऐसा सेट-अप कंस्ट्रेंट प्रोग्रामिंग के अनुरूप है; हालाँकि, अनिवार्य बाधा प्रोग्रामिंग द्विदिश डेटा-प्रवाह बाधाओं का प्रबंधन करती है, अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग एक तरफ़ा डेटा-प्रवाह बाधाओं का प्रबंधन करती है।
वस्तु-उन्मुख
ऑब्जेक्ट-ओरिएंटेड रिएक्टिव प्रोग्रामिंग (ओओआरपी) ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग और रिएक्टिव प्रोग्रामिंग का संयोजन है। शायद इस तरह के संयोजन को बनाने का सबसे स्वाभाविक तरीका इस प्रकार है: विधियों और क्षेत्रों के बजाय, वस्तुओं में ऐसी प्रतिक्रियाएँ होती हैं जो स्वचालित रूप से पुनर्मूल्यांकन करती हैं जब वे अन्य प्रतिक्रियाओं पर निर्भर करती हैं जिन्हें संशोधित किया गया है।[citation needed]
यदि OORP भाषा अपनी अनिवार्य विधियों को बनाए रखती है, तो यह अनिवार्य प्रतिक्रियाशील प्रोग्रामिंग की श्रेणी में भी आएगी।
कार्यात्मक
कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग | कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (एफआरपी) कार्यात्मक प्रोग्रामिंग पर प्रतिक्रियाशील प्रोग्रामिंग के लिए प्रोग्रामिंग प्रतिमान है।
अभिनेता आधारित
अभिनेताओं को प्रतिक्रियाशील प्रणालियों को डिजाइन करने का प्रस्ताव दिया गया है, अक्सर कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग के संयोजन में वितरित प्रतिक्रियाशील प्रणालियों को विकसित करने के लिए कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग (FRP) और प्रतिक्रियाशील धाराएँ।[7][8][9][10]
नियम आधारित
प्रोग्रामिंग भाषाओं की अपेक्षाकृत नई श्रेणी मुख्य प्रोग्रामिंग अवधारणा के रूप में बाधाओं (नियमों) का उपयोग करती है। इसमें घटनाओं की प्रतिक्रियाएँ होती हैं, जो सभी बाधाओं को संतुष्ट करती हैं। यह न केवल घटना-आधारित प्रतिक्रियाओं को सुविधाजनक बनाता है, बल्कि यह प्रतिक्रियाशील कार्यक्रमों को सॉफ्टवेयर की शुद्धता के लिए महत्वपूर्ण बनाता है। नियम आधारित प्रतिक्रियाशील प्रोग्रामिंग भाषा का उदाहरण एम्परसेंड है, जो संबंध बीजगणित में स्थापित है।[11]
कार्यान्वयन
- ReactiveX, RxJs, RxJava, Rx.NET, RxPy और RxSwift सहित कई भाषा कार्यान्वयन के साथ स्ट्रीम, ऑब्जर्वेबल और ऑपरेटरों के साथ प्रतिक्रियाशील प्रोग्रामिंग को लागू करने के लिए एपीआई।
- एल्म (प्रोग्रामिंग भाषा) वेब यूजर इंटरफेस की प्रतिक्रियाशील रचना।
- रिएक्टिव स्ट्रीम, नॉन-ब्लॉकिंग बैकप्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए जेवीएम मानक
- ObservableComputations, क्रॉस-प्लेटफ़ॉर्म .NET कार्यान्वयन।
- Svelte, वैरिएंट जावास्क्रिप्ट सिंटैक्स के रूप में प्रतिक्रियाशीलता लाता है जेएसएक्स (जावास्क्रिप्ट) की तरह दिखता है लेकिन स्वाभाविक रूप से प्रतिक्रियाशील होता है जहाँ जावास्क्रिप्ट सामान्य रूप से नहीं होता है।
- Solid.js, प्रतिक्रियाशील JSX (जावास्क्रिप्ट) टेम्प्लेटिंग के साथ जावास्क्रिप्ट सिंटैक्स सिमेंटिक्स को बदले बिना जावास्क्रिप्ट में प्रतिक्रियाशीलता लाता है।
यह भी देखें
- ऑब्जर्वेबल (कम्प्यूटिंग), रिएक्टिव प्रोग्रामिंग में ऑब्जर्वेबल।
संदर्भ
- ↑ 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.
