ऐसा लगता है कि आप "नेमस्पेस" और "मॉड्यूल" दोनों की शब्दावली को ओवरलोड करना चुन रहे हैं। यह कोई आश्चर्य नहीं होना चाहिए कि आप चीजों को "अप्रत्यक्ष" के रूप में देखते हैं जब वे आपकी परिभाषाओं में फिट नहीं होते हैं।
सी # सहित नामस्थानों का समर्थन करने वाली अधिकांश भाषाओं में, एक नाम स्थान एक मॉड्यूल नहीं है। एक नेमस्पेस, स्कॉपिंग नामों का एक तरीका है। मॉड्यूल स्कूपिंग व्यवहार का एक तरीका है।
सामान्य तौर पर, जबकि .Net रनटाइम एक मॉड्यूल के विचार का समर्थन करता है (एक अलग परिभाषा जो आप उपयोग कर रहे हैं की तुलना में थोड़ी भिन्नता के साथ), यह शायद ही कभी इस्तेमाल किया जाता है; मैंने केवल इसे SharpDevelop में निर्मित परियोजनाओं में उपयोग किया है, ज्यादातर देखा है ताकि आप विभिन्न भाषाओं में निर्मित मॉड्यूल से एक ही DLL का निर्माण कर सकें। इसके बजाय, हम एक गतिशील रूप से जुड़े पुस्तकालय का उपयोग करके पुस्तकालयों का निर्माण करते हैं।
सी # में, नामस्थान किसी भी "अप्रत्यक्ष की परत" के बिना हल करते हैं जब तक कि वे सभी एक ही बाइनरी में न हों; किसी भी अप्रत्यक्ष की आवश्यकता कंपाइलर और लिंकर की एक जिम्मेदारी है जिसे आपको ज्यादा विचार करने की आवश्यकता नहीं है। एक बार जब आप कई निर्भरता के साथ एक परियोजना का निर्माण शुरू करते हैं, तो आप बाहरी पुस्तकालयों का संदर्भ देते हैं। एक बार जब आपके प्रोजेक्ट ने बाहरी लाइब्रेरी (DLL) का संदर्भ लिया है, तो कंपाइलर आपके लिए इसे ढूंढता है।
स्कीम में, यदि आपको किसी बाहरी पुस्तकालय को लोड करने की आवश्यकता है, तो आपको (#%require (lib "mylib.ss"))पहले जैसा कुछ करना होगा , या जैसा कि मुझे याद है, सीधे विदेशी फ़ंक्शन इंटरफ़ेस का उपयोग करें। यदि आप बाहरी बायनेरिज़ का उपयोग कर रहे हैं, तो आपके पास बाहरी बायनेरिज़ को हल करने के लिए समान मात्रा में काम है। संभावना है कि आपने ज्यादातर पुस्तकालयों का उपयोग किया है इसलिए आमतौर पर इसका इस्तेमाल किया जाता है कि एक स्कीम-आधारित शिम है जो आपके पास से सार करता है, लेकिन यदि आपको कभी भी 3 पार्टी लाइब्रेरी के साथ अपना एकीकरण लिखना है, तो आपको अनिवार्य रूप से "लोड" करने के लिए कुछ काम करना होगा। " पुस्तकालय।
रूबी में, मॉड्यूल, नाम स्थान और फ़ाइल नाम वास्तव में बहुत कम जुड़े हुए हैं जितना आप मान लेते हैं; LOAD_PATH चीजों को थोड़ा जटिल बनाता है, और मॉड्यूल घोषणाएं कहीं भी हो सकती हैं। पायथन शायद उन चीजों को करने के करीब है जिस तरह से आपको लगता है कि आप स्कीम में देख रहे हैं, सिवाय इसके कि सी में 3 पार्टी लाइब्रेरी अभी भी एक (छोटी) शिकन जोड़ते हैं।
इसके अतिरिक्त, रूबी, पायथन और लिस्प जैसी गतिशील रूप से टाइप की जाने वाली भाषाओं में आमतौर पर "अनुबंध" के लिए वैधानिक रूप से टाइप की जाने वाली भाषाओं के समान दृष्टिकोण नहीं होता है। गतिशील रूप से टाइप की गई भाषाओं में, आप आमतौर पर "जेंटलमैन एग्रीमेंट" का एक प्रकार स्थापित करते हैं, जो कोड कुछ विधियों का जवाब देगा, और यदि आपकी कक्षाएं एक ही भाषा बोलती दिखाई देती हैं, तो सब अच्छा है। संकलित समय पर इन नियमों को लागू करने के लिए सांख्यिकीय रूप से टाइप की गई भाषाओं में अतिरिक्त तंत्र हैं। C # में, इस तरह के अनुबंध का उपयोग करने से आपको इन इंटरफेस के पालन की कम से कम उपयोगी गारंटी प्रदान करने की अनुमति मिलती है, जो आपको प्लगइन्स और प्रतिस्थापन की समानता की कुछ हद तक गारंटी देता है क्योंकि आप सभी एक ही अनुबंध के खिलाफ संकलन करते हैं। रूबी या स्कीम में, आप रनटाइम पर काम करने वाले परीक्षणों को लिखकर इन समझौतों को सत्यापित करते हैं।
इन संकलित समय की गारंटी से एक औसत दर्जे का प्रदर्शन लाभ है, क्योंकि विधि आह्वान के लिए दोहरे प्रेषण की आवश्यकता नहीं है। लिस्प, रूबी, जावास्क्रिप्ट, या कहीं और इन लाभों को प्राप्त करने के लिए, जो अभी भी विशेष रूप से वीएम में विशेष रूप से संकलित कक्षाओं के थोड़े-थोड़े विदेशी तंत्र की आवश्यकता है।
एक बात यह है कि C # इकोसिस्टम के पास अभी भी इन अपर बाइनरी निर्भरताओं के प्रबंधन के लिए अपेक्षाकृत अपरिपक्व समर्थन है; जावा के पास कई वर्षों से मावेन है ताकि यह सुनिश्चित किया जा सके कि आपके पास अपनी सभी आवश्यक निर्भरताएं हैं, जबकि सी # में अभी भी काफी प्राइमिटिव मेक-अप दृष्टिकोण है जिसमें रणनीतिक रूप से फाइलों को समय से पहले सही स्थान पर रखना शामिल है।