2009-04-02 10 views
5

मुझे एक विशिष्ट प्रकार के फ़ंक्शन के लिए उचित शब्दावली की आवश्यकता है।कोई साइड इफेक्ट्स के साथ एक निर्धारिक कार्य के लिए शब्दावली?

मान लीजिए कि आप अपने SQL डेटाबेस में कोई फ़ंक्शन लिखते हैं, जिसका इनपुट और आउटपुट डेटाबेस लेनदेन के दायरे में निहित है।

यही है, यदि आप इस फ़ंक्शन को डेटाबेस लेनदेन के दायरे में कहते हैं, तो फ़ंक्शन द्वारा उपयोग किए गए सभी डेटा एक ही दायरे में उपलब्ध हैं। यह डेटाबेस तालिका से पूछताछ कर सकता है, लेकिन यह फाइल सिस्टम से फ़ाइल नहीं पढ़ सकता है, या एक वेब साइट पिंग नहीं कर सकता है। यदि आप REPEATABLE READ अलगाव के साथ एक ही लेनदेन के भीतर दो बार फ़ंक्शन को कॉल करते हैं, तो आपको भी वही परिणाम मिलना चाहिए, भले ही आपको एक ही परिणाम मिलना चाहिए अन्य ग्राहक डेटाबेस में परिवर्तन कर रहे हैं।

इसी प्रकार, उसी लेन-देन के दायरे को छोड़कर फ़ंक्शन का कोई साइड इफेक्ट नहीं होता है। डेटाबेस लेनदेन के दायरे से बाहर राज्य में परिवर्तन की अनुमति नहीं है। फ़ंक्शन को ईमेल नहीं भेजना चाहिए, न ही फाइल सिस्टम को लिखना चाहिए, न ही memcached आदि में कोई मान संग्रहीत करना चाहिए। यदि फ़ंक्शन डेटाबेस के भीतर डेटा बदलता है, तो ठीक है क्योंकि अगर कॉलिंग लेनदेन वापस लुढ़का जाता है, तो फ़ंक्शन के प्रभाव होते हैं भी।

फ़ंक्शन के तर्क ठीक हैं, क्योंकि वे मूल रूप से स्थिरांक के रूप में उपयोग किए जाते हैं।

इस प्रकार के फ़ंक्शन के लिए उचित अवधि क्या होगी? "निर्धारक" वास्तव में पर्याप्त विशिष्ट नहीं लगता है। आप इस वर्ग के कार्य का वर्णन कैसे करेंगे?


आपके उत्तरों के लिए धन्यवाद, लेकिन उनमें से कोई भी बिल्कुल मेरे मन में नहीं था। बेवकूफ निकटतम हो जाता है, इसलिए मैंने इसे स्वीकार किए गए उत्तर के रूप में चिह्नित किया। लेकिन आप में से प्रत्येक ने मुझ पर एक उपेक्षा प्राप्त की है।

  • शुद्ध कार्यों कोई दुष्प्रभाव, और उनके परिणाम उनके तर्कों पर आधारित होता है। नतीजे दिए गए परिणाम हमेशा समान होते हैं। यह काम नहीं करता है क्योंकि मेरे पास दिमाग में डेटाबेस फ़ंक्शन डेटा की स्थिति पर आधारित हो सकते हैं, और फ़ंक्शन डेटा की स्थिति को भी प्रभावित कर सकता है।

  • बेवकूफ कार्य डेटा की स्थिति के आधार पर परिणाम लौटा सकता है, और डेटा की स्थिति को देखते हुए परिणाम हमेशा समान होता है। लेकिन यह मेरे मन में जो कुछ भी है उसके लिए काम नहीं करता है; एक बेवकूफ कार्यों के प्रभावों के परिणामस्वरूप एक अपरिवर्तनीय परिणाम हो सकता है इससे कोई फ़र्क नहीं पड़ता कि फ़ंक्शन को कितनी बार बुलाया जाता है। लेकिन लेनदेन अलगाव के भीतर किए गए परिवर्तनों और उस दायरे से बाहर किए गए परिवर्तनों के बीच कोई अंतर नहीं है।

उत्तर

5

क्या आप idempotent के बारे में पूछ रहे हैं?

+1

मुझे लगता है कि वह उससे कुछ मजबूत दिख रहा है; कम से कम, उनके द्वारा प्रदान किए गए सभी स्कोपिंग विवरणों के संबंध में, जो idempotency के लिए प्रासंगिक नहीं हैं। – MarkusQ

+1

नहीं, मुझे नहीं लगता कि उसका कार्य अपने परिणामों पर फ़ंक्शन को कॉल करने के बारे में कुछ भी था ... जो कि बेवकूफता की परवाह करता है। – Varkhan

+0

@ वारखन, आप बेवकूफ की गणित की भावना का उपयोग कर रहे हैं, लेकिन एस लॉट प्रोग्रामिंग में सामान्य परिभाषा का उपयोग कर रहा है। उसका लिंक पढ़ें। – RossFabricant

1

आगे अनुच्छेद तक, मैं सोच रहा था कि लेनदेन के साथ यह एक शुद्ध कार्य था जो एक निहित तर्क के रूप में था। लेकिन जब आप कहते हैं:

फ़ंक्शन का कोई साइड-इफेक्ट नहीं है, उसी लेनदेन के दायरे को छोड़कर। डेटाबेस लेनदेन के दायरे से बाहर राज्य में परिवर्तन की अनुमति नहीं है।

मुझे इतना यकीन नहीं है। क्या आपका मतलब है कि यह लेनदेन लेनदेन के भीतर बदल सकता है लेकिन भविष्य में कॉल पर उनसे संज्ञेय नहीं है?आप कैसे वर्ग है कि साथ:

आप repeatable पढ़ें अलगाव के साथ एक एकल लेनदेन के भीतर दो बार फ़ंक्शन को कॉल करें, तो आप एक ही परिणाम

दूसरे शब्दों में, मिलना चाहिए आप in- सीमित कर रहे हैं असाइनमेंट के लिए लेन-देन साइड इफेक्ट्स (जैसे कि एक झंडा को सही पर सेट करना) जो एक ही प्रभाव पड़ता है यदि कई बार किया जाता है?

+0

मुझे लगता है कि "लेनदेन क्षेत्र" का अर्थ समारोह के भीतर है। कॉलर को शुद्ध रहने के दौरान एक फ़ंक्शन अपनी आंतरिक स्थिति बदल सकता है। इसके बारे में सोचें क्योंकि किसी भी राज्य को प्रभावित नहीं कर सकता है और कुछ भी हो सकता है। –

+0

मुझे अभी भी लगता है कि उस संदर्भ में उपयोग करने के लिए शुद्ध कार्य सबसे उपयुक्त है (भले ही यह सही नहीं है)। – Varkhan

+0

नहीं, मेरा मतलब लेनदेन का दायरा था। यदि फ़ंक्शन डेटा में परिवर्तन करता है, तो उसी लेनदेन के भीतर एक फ़ंक्शन कॉल को परिवर्तन देखना चाहिए। –

6

आप इन pure functions पर भी कॉल कर सकते हैं।

+1

नहीं, क्योंकि इसका दुष्प्रभाव होता है जो लेनदेन करता है; आगे अनुच्छेद देखें। – MarkusQ

+1

इसके अलावा मेरे मन में जो फ़ंक्शन है, वह एक शुद्ध कार्य नहीं है क्योंकि यह डेटाबेस में डेटा के कारण, समान तर्क दिए गए विभिन्न परिणाम दे सकता है। जैसे एक समारोह 'कुलऑर्डरर्सफोरमोन (11) '। –

1

यहां दो अलग-अलग अवधारणाएं हैं, इसलिए आपको एक ही कारण के लिए कई शर्तों को गठबंधन करने की आवश्यकता हो सकती है, "लाल परिपत्र घर" का वर्णन करने के लिए कोई विशेषण नहीं है।

> डेटाबेस लेनदेन के दायरे से बाहर राज्य में परिवर्तन की अनुमति नहीं है।

> यदि फ़ंक्शन डेटाबेस के भीतर डेटा बदलता है, तो ठीक है क्योंकि अगर कॉलिंग लेनदेन वापस लुढ़का जाता है, तो फ़ंक्शन के प्रभाव भी होते हैं।

केवल "डेटाबेस स्कोप" और "सत्र स्कोप" है। एक समारोह में "लेनदेन के दायरे" की कोई अवधारणा नहीं है। किसी फ़ंक्शन के भीतर या के बाहर एक फ़ंक्शन का उपयोग किया जा सकता है जो लेनदेन है, फिर भी फ़ंक्शन के दृष्टिकोण से कोई फर्क नहीं पड़ता।

किसी फ़ंक्शन की आंखों में, "लेन-देन का दायरा" बिल्कुल "डेटाबेस स्कोप" है। एक अप्रतिबद्ध लेन-देन के भीतर हालात प्रतिबद्ध होना चाहिए नहीं है, और के बाद से है कि सभी लेनदेन पर लागू होता है, वहाँ कुछ भी नहीं विशेष के बारे में बताया गया है:

आप repeatable पढ़ें अलगाव के साथ एक एकल लेनदेन के भीतर दो बार फ़ंक्शन को कॉल करें, तो आप मिलना चाहिए एक ही परिणाम, भले ही अन्य क्लाइंट डेटाबेस में परिवर्तन कर रहे हों।

क्योंकि यह लेनदेन का वर्णन कर रहा है, फ़ंक्शन नहीं। हम किसी भी विवरण को सुरक्षित रूप से अनदेखा कर सकते हैं जिसे "लेनदेन" के साथ करना है।

> यह एक डेटाबेस तालिका क्वेरी कर सकता है, लेकिन यह एक वेब साइट, आदि

> डेटाबेस लेन-देन के दायरे से बाहर राज्य में परिवर्तन फाइल सिस्टम से एक फ़ाइल नहीं पढ़ा, या पिंग कर सकते हैं की अनुमति नहीं है। समारोह memcached में ईमेल नहीं भेजना चाहिए, और न ही फाइल सिस्टम के लिए लिखते हैं, और न ही स्टोर एक मूल्य, आदि

> समारोह डेटाबेस के भीतर डेटा बदल देता है, कि ठीक है क्योंकि अगर बुला लेनदेन वापस, तो लुढ़का हुआ है फ़ंक्शन के प्रभाव भी हैं।

> लेकिन लेनदेन [डेटाबेस] अलगाव और उस दायरे से बाहर किए गए परिवर्तनों के बीच किए गए परिवर्तनों के बीच कोई अंतर नहीं है।

निकटतम शब्द शायद "डेटाबेस-स्थानीय" होगा।

> इसी तरह, समारोह कोई दुष्प्रभाव, ही लेनदेन [डेटाबेस] दायरे के भीतर छोड़कर है।

जिसका अर्थ है कि यह साइड इफेक्ट्स है।

> मेरे पास दिमाग में मौजूद डेटाबेस फ़ंक्शंस डेटा की स्थिति पर आधारित हो सकते हैं, और फ़ंक्शन डेटा की स्थिति को भी प्रभावित कर सकता है।

निकटतम शब्द "गैर nullipotent", या "संभवतः-स्टेटफुल" है।

तो निष्कर्ष "एक डीबी-स्थानीय गैर-नलिपोटेंट फ़ंक्शन" है।

+1

अच्छी तरह से तर्क के लिए धन्यवाद! –

संबंधित मुद्दे