30

मुझे प्रोग्राम के लिए अपने हास्केल मॉड्यूल का नाम कैसे देना चाहिए, पुस्तकालय नहीं, और उन्हें पदानुक्रम में व्यवस्थित करें?हास्केल मॉड्यूल नामकरण सम्मेलन

मैं ल्यूमिनोसिटी नामक रे ट्रेसर बना रहा हूं। सबसे पहले मैं इन मॉड्यूल था:

Vector Colour Intersect Trace Render Parse Export 

प्रत्येक मॉड्यूल अपने आप पर ठीक था, लेकिन इस तरह संगठन के अभाव मुझे लगा।

पहले, मैं, Luminosity के तहत हर मॉड्यूल डाल तो उदाहरण Vector अभी था Luminosity.Vector (मुझे लगता है कि यह एक haskell कार्यक्रम के लिए मानक है?)।

तब मैंने सोचा: वेक्टर और रंग स्वतंत्र हैं और उनका पुन: उपयोग किया जा सकता है, इसलिए उन्हें अलग किया जाना चाहिए। लेकिन पुस्तकालयों में बदलने के लिए वे बहुत छोटे हैं।

वे कहाँ जाना चाहिए? पहले से ही (हैकेज पर) Data.Vector और Data.Colour है, तो क्या मुझे उन्हें वहां रखना चाहिए? या क्या यह भ्रम पैदा करेगा (भले ही मैं उन्हें अपने अन्य स्थानीय आयातों के साथ समूहीकृत करता हूं)? यदि नहीं, तो क्या यह Luminosity.Data.Vector या Data.Luminosity.Vector होना चाहिए? मुझे पूरा यकीन है कि मैंने दोनों का इस्तेमाल देखा है, हालांकि शायद मैं एक गैर-परंपरागत संरचना का उपयोग कर एक परियोजना को देखने के लिए हुआ था।

मेरे पास एक साधारण टीजीए छवि निर्यातक भी है (Export) जो चमकदारता से स्वतंत्र हो सकता है। ऐसा लगता है कि सही स्थान Codec.Image.TGA होगा, लेकिन फिर, Luminosity कहीं और होना चाहिए और यदि ऐसा है, तो कहां?

यह अच्छा होगा अगर Structure of a Haskell project या कुछ अन्य विकी ने इसे समझाया।

+2

यदि आप कोड का पुन: प्रयोज्य टुकड़ा बनाना चाहते हैं, तो उसे पुस्तकालय में पैकेज करें। आकार कोई फर्क नहीं पड़ता। –

+2

ज्यामितीय प्राइमेटिव्स के लिए पुन: प्रयोज्य मॉड्यूल - बीजगणितीय प्रकारों, वेक्टर और रंगों के साथ परिभाषित करना इतना आसान है कि गंभीर उपयोग के लिए एक हास्केलर दूसरी लाइब्रेरी पर भरोसा करने के बजाय स्वयं को परिभाषित करना चाहता है। वे तब उनके प्रतिनिधित्व के नियंत्रण में हैं और निर्भरता समस्याओं (एपीआई परिवर्तन, लेखक गायब होने आदि) के बारे में चिंता करने की ज़रूरत नहीं है –

उत्तर

10

सबसे पहले मैं Luminosity

के तहत हर मॉड्यूल डाल मुझे लगता है कि यह एक अच्छा कदम था। यह किसी को भी स्पष्ट करता है जो कोड पढ़ रहा है कि ये मॉड्यूल विशेष रूप से Luminosity प्रोजेक्ट के लिए बनाए गए थे।

आप अनुकरण या सुधार के लिए एक मौजूदा पुस्तकालय पर, या एक अंतर जहां आपको लगता है कि एक विशेष सामान्य पुस्तकालय याद आ रही है, तो वह बहुत कम मामलों में भरने के के इरादे से एक मॉड्यूल लिखते हैं, उपसर्ग और यह नाम सामान्य रूप से छोड़ देते हैं। इसके उदाहरण के लिए, देखें कि pipes पैकेज निर्यात Control.Monad.Trans.Free निर्यात करता है, क्योंकि लेखक, किसी भी कारण से, मुफ्त मोनैड के मौजूदा कार्यान्वयन से संतुष्ट नहीं थे।

तब मैंने सोचा, वेक्टर और रंग बहुत अधिक स्वतंत्र हैं और उनका पुन: उपयोग किया जा सकता है, इसलिए उन्हें अलग किया जाना चाहिए। लेकिन वे लाइब्रेरी में क्रमशः अलग होने के लिए छोटे हैं (125 और 42 लाइन क्रमशः)। वे कहाँ जाना चाहिए?

तो आपको एक अलग पुस्तकालय नहीं बनाते हैं, तो शायद उन्हें Luminosity.Vector और Luminosity.Colour पर छोड़ दें। यदि आप अलग पुस्तकालय बनाते हैं, तो उन पुस्तकालयों के लक्षित दर्शकों को ईमेल करने का प्रयास करें और देखें कि अन्य लोगों को लगता है कि इन पुस्तकालयों का नाम और वर्गीकरण किया जाना चाहिए। चाहे आप इन्हें अलग पुस्तकालयों में विभाजित करते हैं या नहीं, पूरी तरह से आप पर निर्भर हैं और आपको लगता है कि ये अलग-अलग पुस्तकालय अन्य लोगों के लिए कितना लाभ प्रदान कर सकते हैं।

+0

मैंने आपका जवाब स्वीकार कर लिया क्योंकि मुझे लगता है कि इससे सबसे ज्यादा मदद मिली और मेरे लिए विशिष्ट था, लेकिन मैंने आपके, नॉर्मन और स्टीफन (प्रश्न पर टिप्पणी) सलाह को जोड़ा। मैं सबकुछ 'चमकदारता के नीचे रखूंगा।जैसा आपने कहा था। स्टीफन ने कहा कि मैं अपने छोटे मॉड्यूल से लाइब्रेरी बनाने या उपसर्ग को छोड़ने से परेशान नहीं करूंगा, क्योंकि हर कार्यक्रम शायद वैसे भी अपने स्वयं के वैक्टर और रंग चाहता है। और नॉर्मन के कारणों के लिए मैं 'चमकदारता' के नीचे पदानुक्रम शुरू करने के बजाए सबकुछ सपाट रखूंगा। – mk12

18

जब तक आपका प्रोग्राम वास्तव में बड़ा, पदानुक्रम में मॉड्यूल व्यवस्थित न करें। क्यों नहीं? चूंकि कंप्यूटर पदानुक्रम में अच्छे हैं, लेकिन लोग नहीं हैं। लोग सार्थक नामों पर अच्छे हैं। यदि आप अच्छे नाम चुनते हैं तो आप एक फ्लैट नाम स्थान में 150 मॉड्यूल आसानी से संभाल सकते हैं।

मुझे लगता है कि [एक फ्लैट नाम स्थान] संगठन की कमी है।

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

ये समस्याएं प्रोग्रामिंग भाषा से काफी हद तक स्वतंत्र हैं जिनका आप उपयोग कर रहे हैं। मैं उत्पाद लाइनों और कार्यक्रम परिवारों पर डेविड पारनास के कुछ काम पढ़ने की सलाह देता हूं, और मैथियस ब्लूम के अंडरपेरिएटेड पेपर Hierarchical Modularity पर भी काम करता हूं। ये कार्य आपको कुछ और ठोस विचार देंगे जब पदानुक्रम किसी उद्देश्य को पूरा करना शुरू कर देता है।सब से

+1

यह एक दिलचस्प परिप्रेक्ष्य है! मेरे पास आमतौर पर मेरे कार्यक्रमों में पदानुक्रमिक संगठन के कम से कम * कुछ * रूप होते हैं। "वास्तव में बड़ा" के लिए आपका ऑर्डर-ऑफ-आयाम सीमा क्या है? –

+0

मैं आपके तर्क को समझता हूं, लेकिन मैं इस विचार से असहमत हूं कि यह प्रोग्रामिंग भाषा से स्वतंत्र है। कम से कम टकराव नामकरण से बचने के लिए, एक स्तर पेश किया जाना चाहिए ('चमकदारता * * ') - मुझे यकीन नहीं है कि क्या आप इसे पदानुक्रम के रूप में मानते हैं। मैं वास्तव में पदानुक्रम के पेशेवरों और विपक्ष के बारे में नहीं पूछ रहा था, मैं विशेष रूप से हास्केल सम्मेलनों के बारे में पूछ रहा हूं। हो सकता है कि यह बाइकहेडिंग है, लेकिन हास्केल 'बेस' पदानुक्रम (साथ ही हैकेज पर संकुल के उन), जावा या पायथन के सम्मेलनों की तुलना में काफी अलग और कम सरल लगता है। – mk12

+0

फ्लैट बनाम पदानुक्रम चर्चा के लिए, मेरे 8-मॉड्यूल कार्यक्रम के लिए पदानुक्रम बनाने के पीछे मेरा तर्क यह था: लगभग आधे मॉड्यूल के पास रे ट्रेसिंग के साथ कुछ लेना देना नहीं था। मैं उन्हें स्थानीय रूप से अपने फ़ाइल ब्राउज़र में उचित रूप से व्यवस्थित कर सकता हूं, लेकिन गिटहब पर वे सभी वर्णानुक्रमित हैं। मैंने सोचा कि इससे लोगों को संबंधित मॉड्यूल को समूहीकृत करके इसे आसान बनाना आसान हो जाएगा। जो आप बहस कर रहे हैं उसके ठीक विपरीत लगता है। – mk12

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

  • कोई संबंधित समस्या नहीं^_^