एफआरपी शुद्ध कार्यों के माध्यम से घटनाओं और व्यवहारों के स्ट्रीमिंग के बारे में है। अभिनेता मॉडल - कम से कम, जैसा कि अक्का में कार्यान्वित किया जाता है - संभावित अशुद्ध वस्तुओं के माध्यम से अपरिवर्तनीय संदेशों (जिसे असतत घटना माना जा सकता है) को स्ट्रीमिंग करने के बारे में है, जिसे अभिनेता कहा जाता है।
इसलिए सतह पर वे संबंधित प्रतीत होते हैं।
हम इससे संबंधित कैसे कह सकते हैं? इसके अलावा, विभिन्न एप्लिकेशन डोमेन के लिए उनमें से कौन सा अधिक उपयुक्त हो सकता है?
जवाबों:
न तो अभिनेता और न ही FRP स्ट्रीमिंग के बारे में हैं। अभिनेता किसी आउटपुट स्ट्रीम के बाहरी कॉन्फ़िगरेशन का भी समर्थन नहीं करते हैं।
एफआरपी को एक रैखिक समयरेखा पर अपने मॉडलिंग सिग्नल और घटनाओं की दृढ़ता से विशेषता है, जो एफआरपी व्यवहार को एक नियतकालिक तरीके से रचना करने में सक्षम बनाता है। अभिनेताओं को गैर-नियतात्मक क्रम में संदेशों को संसाधित करने की दृढ़ता से विशेषता होती है, और इसमें कोई भी रचना गुण होता है (यानी आप एक बड़े अभिनेता के रूप में दो अभिनेताओं की व्यवस्था का इलाज नहीं कर सकते हैं)।
यदि आप समानताएं तलाश रहे हैं, तो दोनों अभिनेताओं और FRP का लांबा कैलकुलस के साथ घनिष्ठ संबंध है। दोनों मानव इनपुट के लिए सिस्टम को उत्तरदायी बना सकते हैं। दोनों आंतरिक (स्थानीय) राज्य के मॉडलिंग का समर्थन करते हैं।
एफआरपी अभिन्न या संचायक (समय के साथ गुना) के माध्यम से स्थानीय राज्य का समर्थन करता है, जबकि अभिनेता मॉडल प्रत्येक अभिनेता को वर्तमान संदेश के जवाब में अगले संदेश के लिए अपने व्यवहार को निर्दिष्ट करने की अनुमति देकर राज्य का समर्थन करता है। स्थानीय राज्य के लिए यह व्यापक समर्थन एफआरपी और अभिनेताओं दोनों को लाइव प्रोग्रामिंग (या प्रोग्राम कोड के रनटाइम अपग्रेड) के लिए अपर्याप्त बनाता है; महत्वपूर्ण अवस्था को खोना बहुत आसान हो जाता है।
अनुप्रयोग डोमेन के बारे में:
अभिनेता मॉडल खुली प्रणालियों के लिए अच्छी तरह से अनुकूल है, जहां हम रनटाइम पर अभिनेताओं को स्थापित या बनाए रखने की इच्छा कर सकते हैं। अभिनेताओं का मॉडल भी वितरित प्रणालियों के लिए कमजोर रूप से अनुकूल है, क्योंकि संदेशों के गैर-निर्धारक आदेश एक अनुरूप कार्यान्वयन को आसान बना सकते हैं। (कारण अभिनेताओं को वितरित प्रणालियों के लिए अधिक दृढ़ता से अनुकूल नहीं है कि यह सुनिश्चित करना कि एक संदेश 'एक बार और केवल एक बार' आता है, विघटन के सामना करने में काफी मुश्किल है, और अभिनेताओं को भी वितरित जीसी की आवश्यकता होती है, जो एक दर्द है।)
एफआरपी अच्छी तरह से बंद प्रणालियों के अनुकूल है जो समय के साथ काम करते हैं - जैसे रोबोट नियंत्रक, संगीत प्रोग्रामिंग, कम्प्यूटेशनल खिलौने। नियतात्मकता और संरचनागत विशेषताएं एक्टर्स के साथ काम करने के लिए एफआरपी को अधिक सुविधाजनक बनाती हैं, कम से कम उन मामलों में जहां एफआरपी सीधे समाधान का मॉडल तैयार कर सकता है। एफआरपी को प्रभावों के साथ एकीकृत करना (सुरुचिपूर्ण ढंग से, अशुद्धता के साथ मॉडल को हैक किए बिना) मुश्किल साबित हुआ है। 'वर्महोल' के माध्यम से प्रभावी एफआरपी पर हाल ही में काम किया गया है - संसाधनों के लिए प्रभावी, अद्वितीय या रैखिक टाइप किया गया।
ऐसे अन्य मॉडल हैं जो FRP और अभिनेताओं के बीच कहीं झूठ बोलते हैं।
जॉन पॉल मॉरिसन द्वारा विकसित फ्लो बेस्ड प्रोग्रामिंग (एफबीपी) वास्तव में संदेशों की स्ट्रीमिंग का समर्थन करता है।
समय ताना प्रोटोकॉल (या लाइटवेट टाइम ताना (LTW) पर अधिक हालिया काम) संदेश पारित करने के लिए एक अधिक नियंत्रित और संरचनागत धारणा प्रदान करने के लिए तार्किक समयरेखा पर अभिनेताओं जैसे संदेश देता है। टाइम ताना अक्सर बड़े समानांतर और वितरित प्रणालियों, जैसे वैज्ञानिक कंप्यूटिंग के लिए उपयोग किया जाता है। मूल समय ताना इंटरैक्टिव simulatons (मानव इनपुट के लिए जवाबदेही) के लिए अनुपयुक्त था, और LTW केवल मामूली रूप से अनुकूल है।
मैं रिएक्टिव डिमांड प्रोग्रामिंग (आरडीपी) विकसित कर रहा हूं जो उत्तरदायी, संरचनागत, एफआरपी-जैसे हेरफेर और खुले और वितरित प्रणालियों में संकेतों के प्रसंस्करण को सक्षम बनाता है, और स्थानीय स्थिति को समाप्त करता है। RDP समय-समय पर संकेतों द्वारा संसाधन राज्य पर कम्यूटेटिव, आलंबनपूर्ण प्रभाव के लिए साइड-इफेक्ट्स को बाधित करने के द्वारा प्राप्त किया जाता है। RDP को संसाधन और राज्य मॉडल के पुनर्विचार की आवश्यकता होती है।
मैं बताना चाहता हूं कि वे व्यावहारिक दृष्टिकोण से कैसे अलग हैं:
1) अभिनेता अन्य अभिनेताओं को संदेश भेजते हैं, यह संदेश गुजरना स्पष्ट और अनिवार्य रूप से वर्णित है ।
उदाहरण के लिए:
send msg to Actor137।
2) एफआरपी में डेटा प्रवाह को घोषित रूप से वर्णित किया जाता है :
उदाहरण के लिए:
Cell134=Cell185+Cell42।
पासिंग संदेश FRP फ्रेमवर्क द्वारा संभाला जाता है और आपको "मैन्युअल रूप से" वर्णन करने की आवश्यकता नहीं है कि एक सेल (एंकर से अभिनेता, संदेश को राज्य, उर्फ व्यवहार) से दूसरे में संदेश कैसे पारित किया जाए।
दूसरे शब्दों में:
कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग का सार घोषणा के समय पूरी तरह से एक मूल्य के गतिशील व्यवहार को निर्दिष्ट करना है । तो सभी निर्भरताएं Cell134घोषणा बिंदु पर परिभाषित की जाती हैं।
यह अभिनेता मॉडल के लिए सही नहीं है । अभिनेता के व्यवहार को प्रभावित करने वाले अभिनेताओं Aको स्रोत कोड में उसी स्थान पर परिभाषित नहीं किया जाता है जहां अभिनेता Aपरिभाषित होता है।
हाल ही में मैंने देखा कि दोनों के बीच एक दिलचस्प संकर है: अक्का धाराएँ, जहाँ डेटाफ़्लो को घोषित रूप से वर्णित किया जाता है लेकिन अभिनेताओं के लिए लागू किया जाता है।
एक और अंतर यह है: अभिनेताओं को async करते हैं जबकि FRP तुल्यकालिक (अक्सर गड़बड़ मुक्त) हो जाता है।