मैं समझता हूं कि आप ऐसा क्यों करना चाहते हैं, लेकिन दुर्भाग्य से, यह केवल एक भ्रम हो सकता है कि हास्केल कक्षाएं आपके कहने के तरीके में "खुली" लगती हैं। कई लोगों को लगता है कि ऐसा करने की संभावना हास्केल विनिर्देशन में एक बग है, जिन कारणों से मैं नीचे बताऊंगा। वैसे भी, यदि यह वास्तव में उदाहरण के लिए उपयुक्त नहीं है, तो आपको उस मॉड्यूल में घोषित किए जाने की आवश्यकता होती है जहां कक्षा घोषित की जाती है या मॉड्यूल में जहां प्रकार घोषित किया जाता है, वह संभवतः एक संकेत है कि आपको newtypeया किसी अन्य आवरण का उपयोग करना चाहिए। अपने प्रकार के आसपास।
संकलक की सुविधा की तुलना में अनाथ उदाहरणों को अधिक गहराई तक चलाने से बचने की आवश्यकता है। यह विषय बल्कि विवादास्पद है, जैसा कि आप अन्य उत्तरों से देख सकते हैं। चर्चा को संतुलित करने के लिए, मैं इस दृष्टिकोण की व्याख्या करने जा रहा हूं कि किसी को कभी भी, कभी भी, अनाथ उदाहरणों को लिखना चाहिए, जो मुझे लगता है कि अनुभवी हास्केलर्स के बीच बहुमत की राय है। मेरी अपनी राय कहीं बीच में है, जिसे मैं अंत में समझाऊंगा।
समस्या इस तथ्य से उपजी है कि जब एक ही वर्ग और प्रकार के लिए एक से अधिक उदाहरण घोषणा मौजूद हैं, तो मानक हास्केल में कोई तंत्र नहीं है जो यह निर्दिष्ट करें कि किसका उपयोग करना है। बल्कि, प्रोग्राम को कंपाइलर द्वारा अस्वीकार कर दिया जाता है।
इसका सबसे सरल प्रभाव यह है कि आपके पास एक पूरी तरह से काम करने वाला कार्यक्रम हो सकता है जो किसी अन्य व्यक्ति द्वारा आपके मॉड्यूल की दूर की निर्भरता में किए गए बदलाव के कारण अचानक संकलन करना बंद कर देगा।
इससे भी बदतर यह है कि एक कार्यशील कार्यक्रम के कारण एक परिवर्तन के कारण रनटाइम पर दुर्घटनाग्रस्त होना शुरू हो जाता है । आप एक ऐसी विधि का उपयोग कर सकते हैं जिसे आप मान रहे हैं कि एक निश्चित उदाहरण घोषणा से आता है, और यह चुपचाप एक अलग उदाहरण द्वारा प्रतिस्थापित किया जा सकता है जो आपके प्रोग्राम को बेवजह क्रैश करने के लिए पर्याप्त कारण है।
जो लोग गारंटी चाहते हैं कि ये समस्याएं उनके साथ कभी नहीं होंगी, उन्हें इस नियम का पालन करना चाहिए कि यदि किसी ने, कहीं भी, कभी भी एक निश्चित प्रकार के लिए एक निश्चित वर्ग का उदाहरण घोषित किया है, तो किसी भी अन्य कार्यक्रम में किसी अन्य उदाहरण को फिर से घोषित नहीं किया जाना चाहिए। किसी से भी। बेशक, newtypeएक नया उदाहरण घोषित करने के लिए एक का उपयोग करने का समाधान है , लेकिन यह हमेशा कम से कम एक छोटी सी असुविधा है, और कभी-कभी एक प्रमुख है। इसलिए इस अर्थ में, जो लोग जानबूझकर अनाथ उदाहरण लिखते हैं, बल्कि उन्हें थोपा जा रहा है।
तो इस समस्या के बारे में क्या किया जाना चाहिए? विरोधी अनाथ-उदाहरण शिविर का कहना है कि जीएचसी चेतावनी बग है, यह एक त्रुटि होने की आवश्यकता है जो अनाथ उदाहरण घोषित करने के किसी भी प्रयास को अस्वीकार करती है। इस दौरान, हमें आत्म-अनुशासन का प्रयोग करना चाहिए और हर कीमत पर इनसे बचना चाहिए।
जैसा कि आपने देखा है, ऐसे लोग हैं जो उन संभावित समस्याओं के बारे में चिंतित नहीं हैं। वे वास्तव में, अनाथ उदाहरणों को चिंताओं को अलग करने के लिए एक उपकरण के रूप में उपयोग करने के लिए प्रोत्साहित करते हैं, जैसा कि आप सुझाव देते हैं, और कहते हैं कि किसी मामले-दर-मामले के आधार पर सुनिश्चित करना चाहिए कि कोई समस्या नहीं है। अन्य लोगों के अनाथ उदाहरणों से मुझे यह महसूस करने में काफी असुविधा हो रही है कि यह रवैया बहुत बड़ा है।
मुझे लगता है कि हास्केल के आयात तंत्र के विस्तार को जोड़ने के लिए सही समाधान होगा जो कि उदाहरणों के आयात को नियंत्रित करेगा। यह पूरी तरह से समस्याओं को हल नहीं करेगा, लेकिन यह अनाथ उदाहरणों से होने वाले नुकसान से हमारे कार्यक्रमों की रक्षा करने की दिशा में कुछ मदद करेगा जो पहले से ही दुनिया में मौजूद हैं। और फिर, समय के साथ, मैं आश्वस्त हो सकता हूं कि कुछ सीमित मामलों में, शायद एक अनाथ उदाहरण इतना बुरा नहीं हो सकता है। (और यह बहुत प्रलोभन देने का कारण है कि कुछ अनाथ-विरोधी शिविर मेरे प्रस्ताव के विरोध में हैं।)
इस सब से मेरा निष्कर्ष यह है कि कम से कम समय के लिए, मैं दृढ़ता से सलाह दूंगा कि आप किसी भी अनाथ उदाहरण की घोषणा करने से बचें, यदि कोई अन्य कारण नहीं है तो दूसरों पर विचार करें। एक का उपयोग करें newtype।