क्लोजर में नेमस्पेस का उपयोग करने के लिए आम सम्मेलन क्या हैं?

Question

क्लोजर में नामस्थानों के उपयोग के लिए मुझे अच्छी सलाह और सामान्य प्रथाओं को ढूंढने में परेशानी हो रही है। मुझे एहसास है कि नामस्थान जावा पैकेज के समान नहीं हैं इसलिए मैं क्लोजर में सम्मेलनों को छेड़छाड़ करने की कोशिश कर रहा हूं, जो निर्धारित करने के लिए आश्चर्यजनक रूप से कठिन लगते हैं।

मुझे लगता है कि मेरे पास एक बहुत अच्छा विचार है कि कैसे clj फ़ाइलों में कार्यों को विभाजित करना है और यहां तक ​​कि मोटे तौर पर मैं उन फ़ाइलों को निर्देशिकाओं में व्यवस्थित करना चाहता हूं। लेकिन इससे परे मुझे अपने देव पर्यावरण के लिए यांत्रिकी खोजने में परेशानी हो रही है। कुछ अंतर-संबंधित प्रश्न:

1. क्या मैं क्लोजर नेमस्पेस के लिए समान विशिष्टता सम्मेलनों का उपयोग करता हूं क्योंकि मैं आमतौर पर जावा पैकेज के लिए उपयोग करता हूं? [यानी पिछला-कंपनी-डोमेन.project.subsystem]
2. क्या मुझे अपनी फ़ाइलों को एक निर्देशिका संरचना में सहेजना चाहिए जो मेरे नामस्थान से मेल खाता हो? [अला जावा]
3. यदि मेरे पास एकाधिक नामस्थान हैं, तो क्या मुझे अपने सभी कोड को जार में संकलित करने और इसे अपने क्लासपाथ में जोड़ने के लिए इसे सुलभ बनाने की आवश्यकता है?
4. प्रत्येक नेमस्पेस एक जार से संकलित होना चाहिए? या क्या मुझे एक जार बनाना चाहिए जिसमें कई नामस्थानों से क्लोज कोड शामिल है?

धन्यवाद ...

Answer 1

1. मुझे लगता है कि यह ठीक है अगर आपको लगता है कि यह मदद करता है, लेकिन कई Clojure परियोजनाओं ऐसा नहीं करते हैं - cf. Compojure (एक शीर्ष स्तरीय compojure एनएस और विभिन्न compojure का उपयोग कर। * विशिष्ट कार्यक्षमता के लिए एनएस), अंगूठी, Leiningen ... क्लोजर खुद क्लोजर का उपयोग करता है। * (और clobure.contrib। * Contrib पुस्तकालयों के लिए), लेकिन यह एक विशेष मामला है, मुझे लगता है।

2. हाँ! आप बिल्कुल ऐसा करना चाहते हैं, या फिर क्लोजर आपके नामस्थान नहीं ढूंढ पाएगा। यह भी ध्यान रखें कि आप नेमस्पेस नामों में अंडरस्कोर या फ़ाइल नामों में हाइफ़न का उपयोग नहीं करते हैं और जहां भी आप नामस्थान नाम में हाइफ़न का उपयोग करते हैं, आपको फ़ाइल नाम में अंडरस्कोर का उपयोग करना होगा (ताकि my.cool-project को cool_project.clj नामक फ़ाइल में परिभाषित किया गया हो my नामक निर्देशिका में)।

3. आपको यह सुनिश्चित करने की ज़रूरत है कि आपकी सारी चीज़ें क्लासपाथ पर हैं, लेकिन इससे कोई फर्क नहीं पड़ता कि यह एक जार, एकाधिक जार, फाइल सिस्टम पर जार और निर्देशिका का मिश्रण है ... जब तक यह आज्ञा करता है सही नामकरण सम्मेलन (आपका बिंदु संख्या 2) आपको ठीक होना चाहिए।

   हालांकि, आगे के- समय बातें संकलन नहीं है वहाँ ऐसा करने के लिए कोई विशेष कारण है कि अगर - यह एक थोड़ा सुधार लोडिंग समय के अलावा किसी भी लाभ प्रदान किए बिना Clojure के विभिन्न संस्करणों भर में पोर्टेबल होने से अपने कोड को रोक सकता है ।

   आपको कभी-कभी कुछ जावा इंटरऑप परिदृश्यों में एओटी संकलन का उपयोग करने की आवश्यकता होगी - प्रासंगिक कार्यों/मैक्रोज़ का दस्तावेज़ीकरण हमेशा उल्लेख करता है। Clojure.contrib में एओटी की आवश्यकता वाले चीजों के उदाहरण हैं; मुझे इसकी आवश्यकता नहीं है, इसलिए मैं विवरण के तरीके में ज्यादा प्रदान नहीं कर सकता।

4. मैं कहूंगा कि आपको कोड की कार्यात्मक इकाइयों के लिए जार का उपयोग करना चाहिए। जैसे कॉम्पोजर और रिंग को कई जारों के रूप में पैक किया जाता है जिसमें कई नामस्थान होते हैं जो एक साथ पूरे पैकेज को लिखते हैं। इसके अलावा, clojure.contrib को कई असंबद्ध पुस्तकालयों के साथ एक जार के रूप में विशेष रूप से पैक किया जाता है; लेकिन वह फिर से एक विशेष मामला हो सकता है।

   दूसरी ओर, एक ही जार जिसमें आपकी सभी प्रोजेक्ट्स कोड शामिल हैं, इसकी निर्भरता कभी-कभी तैनाती के लिए उपयोगी हो सकती है। the Leiningen build tool और इसकी 'uberjar' सुविधा देखें, यदि आपको लगता है कि इस तरह की चीज आपके लिए उपयोगी हो सकती है।

Answer 2

1. सच पूछिये तो, आवश्यक नहीं है, हालांकि कई जावा परियोजनाओं विशेष रूप से आंतरिक परियोजनाओं या निजी एपीआई के लिए कि सम्मेलन गिरावट आई है और साथ ही,। हालांकि एकल-सेगमेंट नामस्थान से बचें, जिसके परिणामस्वरूप डिफ़ॉल्ट पैकेज में क्लासफ़ाइल उत्पन्न हो जाएंगे।
2. हां।

के बारे में 3 & 4, पैकेजिंग और AOT संकलन पूरी तरह से नाम स्थान सम्मेलनों के प्रश्न के orthogonal हैं।