स्वचालित प्रोग्रामिंग: कोड लिखने वाला कोड [बंद] लिखता है


105

द प्रैजमैटिक प्रोग्रामर पुस्तक को पढ़ने के बाद , मुझे जो एक तर्क मिला, वह सबसे दिलचस्प था "कोड लिखें जो कोड लिखता है"।

मैंने इसके बारे में कुछ और स्पष्टीकरण या लेखों के लिए नेट पर खोज करने की कोशिश की, और जब मुझे इस विषय पर कुछ अच्छे लेख मिले, तब भी मुझे कोई विशिष्ट कोड कार्यान्वयन या अच्छे उदाहरण नहीं मिले।

मुझे लगता है कि यह अभी भी एक आम तर्क नहीं है, कुछ ऐसा है जिसमें प्रलेखन की कमी है या यह इतने सारे लोगों द्वारा गले नहीं लगाया गया है, और मैं इसके बारे में अधिक जानना चाहूंगा।

आप विषय के बारे में क्या सोचते हैं? क्या यह कुछ ऐसा है जो वास्तव में आपकी उत्पादकता बढ़ाएगा? पुस्तकों, ब्लॉगों, स्लाइडशो, आदि के बीच इस विषय पर कुछ अच्छे संसाधन क्या हैं?


मुझे इसके कार्यान्वयन को बेहतर ढंग से समझने की अनुमति देने के लिए कुछ कोड उदाहरणों की बहुत सराहना की जाएगी।


यहाँ विकि पृष्ठ विभिन्न प्रासंगिक प्रोग्रामिंग तकनीकों, मेटा प्रोग्रामिंग, उत्पादक प्रोग्रामिंग और कोड पीढ़ी की तरह साथ इस विषय पर।


32
मैंने एक बार कोड लिखा था जिसने कोड लिखा था जो कोड लिखा था ... :)
बेंजोल

9
@ बेनजोल: क्या आप लिस्प में लिख रहे थे?
12

11
इसके अतिरिक्त, सर्वर-साइड भाषाएँ हर समय HTML, CSS और जावास्क्रिप्ट उत्पन्न करके करती हैं। आपके पास एक सर्वर-साइड स्क्रिप्ट हो सकती है जो एक सर्वर-साइड स्क्रिप्ट बनाती है जो जावास्क्रिप्ट के साथ html बनाती है जो अधिक html बनाती है, और कोई भी इस बारे में आंख नहीं झुकाएगा कि यह कितना आम है।
zzzzBov

8
यदि आप पहले से ही नहीं है, तो इस आईबीएम डेवलपरवर्क्स लेख श्रृंखला की जांच करें: " मेटाप्रोग्रामिंग की कला " भाग 1 , भाग 2 और भाग 3
जॉन टोबलर

3
AtomWeaver ( atomweaver.com ) स्वचालित प्रोग्रामिंग का एक अच्छा उदाहरण है: सबसे पहले, आप लुआ में पुन: प्रयोज्य मिनी-प्रोग्राम बनाते हैं। फिर, आप इन परिसंपत्तियों का पुन: उपयोग करके अपने सिस्टम को मॉडल करते हैं। AtomWeaver तब एक Lua प्रोग्राम बुनता है जिसमें सिस्टम के अंतिम स्रोत कोड को उत्पन्न करने के लिए आपके "मिनी-जनरेटर" होते हैं। फिर आप अपने मॉडल को फिर से बना सकते हैं और पुनः उत्पन्न कर सकते हैं।
रुई करैडो

जवाबों:


49

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

उत्पादकता के लिए: मैं अपने लगभग सभी विकास कार्यों में एक प्रमुख तकनीक के रूप में मेटाप्रोग्रामिंग का उपयोग कर रहा हूं, और यह स्पष्ट रूप से बहुत मदद करता है, दोनों कोड आकार को कम करने और इसकी पठनीयता को बढ़ाता है। डोमेन विशिष्ट भाषाओं का उपयोग करने में महत्वपूर्ण है , और मेटाप्रोग्रामिंग उन्हें लागू करने के सबसे कुशल तरीकों में से एक है।


67

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

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

एक किताब मैं इस विषय पर पढ़ने मज़ा आया था Metaprogramming रूबी (आप रूबी भाषा जानते हैं)


टिप्पणी में निम्नलिखित प्रश्न के बाद संपादित करें:

यह उपयोगी क्यों होना चाहिए यह अभी भी मुझे कोड बनाना है? क्या मुझे उपयोगकर्ता इनपुट के आधार पर विभिन्न चीजों को उत्पन्न करने में सक्षम कोड लिखना चाहिए, ताकि मैं इसे बार-बार उपयोग कर सकूं?

सबसे पहले, मेटाप्रोग्रामिंग एक लक्ष्य नहीं है, बल्कि एक उपकरण है। मेटाप्रोग्रामिंग का उपयोग न करें क्योंकि "इसके कूल" या "X ने कहा कि प्रत्येक डेवलपर को इसका उपयोग करना चाहिए"।

मुझे लगता है कि मेटाप्रोग्रामिंग का उपयोग करने का एक अच्छा कारण कुछ सामान्य पैटर्न (पैटर्न जो कुछ दोहराता है) को सामान्य बनाना है जो आपने अपने कोड में पाया है और कोई अन्य सामान्य प्रोग्रामिंग टेकनीक (विरासत, डिजाइन पैटर्न, आदि) प्राप्त नहीं कर सकता है।

जैसा कि जॉर्डन ने कहा , एक विशिष्ट उपयोग मामला डेटाबेस हैंडलिंग और ओआरएम (ऑब्जेक्ट रिलेशन मैपिंग) है। एक बार फिर, रूबी में, आपको ActiveRecord को देखना चाहिए जो ORM पर लागू होने वाले मेटाप्रोग्रामिंग का एक बड़ा उदाहरण है।

अंतिम नोट के रूप में:

ऐसा मत सोचो कि "मैं मेटाप्रोग्रामिंग लागू करना चाहता हूं, मैं इसे अपने कोड में कहां लागू कर सकता हूं?"।

सोचें "मैं इस पैटर्न को अपने कोड में दोहरा रहा हूं, मुझे कोड को कुछ छोटे और अधिक पुन: उपयोग में लाने का तरीका नहीं मिल रहा है। शायद मेटाप्रोग्रामिंग मेरी मदद कर सकता है?"


3
@Jose: आमतौर पर आप टेम्प्लेट के माध्यम से कोड उत्पन्न करते हैं। उदाहरण के लिए या दृश्य स्टूडियो T4 टेम्पलेट्स के लिए अपाचे (N-) वेग है। तब आपके पास बस एक प्रोग्राम होता है जो मेटाडेटा को आपके टेम्प्लेट में फीड करता है और तब से नई फाइल बनाता है। यह बहुत आसान है और मैं यूआई-कंकाल, एंटिटी इत्यादि उत्पन्न करने के लिए हर समय कर रहा हूं
फाल्कन

2
@ जोसे फ़ेटी, लिस्प मैक्रोज़ (या क्लोज़र, या नेमर्ले, आपकी पसंदीदा प्राथमिकताओं के आधार पर) पर करीब से नज़र डालें।
एसके-लॉजिक

1
मुझे लगता है कि नीति या राज्य जैसे कुछ पैटर्न को प्रतिस्थापित कर सकते हैं, लेकिन कोई रनटाइम लागत के साथ। यह केवल उन समस्याओं के लिए नहीं है, जिन्हें सामान्य रीफैक्टरिंग के साथ हासिल नहीं किया जा सकता है, बल्कि कुछ समय के लिए एक बेहतर विकल्प भी है।
deadalnix

1
@ जोसे फेती: मैं देख रहा हूं कि आप कुछ पायथन को जानते हैं। इसमें मेटाप्रोग्रामिंग क्षमताएं भी हैं, हालांकि मैंने वास्तव में उन का उपयोग नहीं किया है। खतरनाक
किट

3
@ फाल्कन: आईएमओ जो कोड उत्पन्न करने का सबसे खराब तरीका है; बिना बिल्ट-इन मेटा-प्रोग्रामिंग सुविधा वाली भाषाओं के लिए यह बहुत खराब काम है। जावा या सी # उत्पन्न करने के बजाय, उस कोड को उच्च-स्तरीय JVM या .NET भाषा में लिखना बेहतर होगा।
केविन क्लाइन

19

और भी बेहतर, उस कोड का उपयोग करें जिसे किसी और ने लिखा है जो आपके लिए अपना कोड लिखता है।

कोड स्वचालन आमतौर पर ORM और अन्य डेटाबेस इंटरैक्शन कोड के लिए अच्छा है, और निश्चित रूप से दोहराए जाने वाले लेकिन समान कोड बिल्डिंग के लिए।

बेशक, यदि आप समान दिखने वाली बहुत सारी कक्षाओं का निर्माण कर रहे हैं, तो शायद आप एक गतिशील भाषा में एक ही चीज़ को बहुत जल्द पूरा कर सकते हैं, लेकिन मैं पचाता हूं।

यह कई लोगों द्वारा गले लगाया गया है, हालांकि आपको अक्सर कोड जनरेटर के रूप में लेबल किए गए सॉफ़्टवेयर मिलेंगे।

कोडस्मिथ और MyGeneration जैसी कंपनियों और उत्पादों को देखें, या इस विकिपीडिया लेख पर एक ब्राउज़ करें: http://en.wikipedia.org/wiki/Comparison_of_code_generation_tools


6
यह कोई बेहतर नहीं है। आपका कीमती थोड़ा बहुत खुद का कोड कुछ अन्य ब्लोके कोड जेनरेशन टूल द्वारा ठीक से प्रबंधित नहीं किया जा सकता है, क्योंकि अन्य ब्लोक को आपकी बारीकियों के बारे में कुछ भी नहीं पता है। मेटाप्रोग्रामिंग का सबसे अधिक उत्पादक उपयोग डोमेन विशिष्ट भाषाओं को लागू कर रहा है - और, जैसा कि नाम से पता चलता है, वे आपके बहुत ही समस्या डोमेन के लिए विशिष्ट हैं, उन्हें किसी और द्वारा लागू नहीं किया जा सकता है लेकिन आप।
एसके-तर्क

@ एसके-तर्क: ओआरएम उत्पन्न कोड के बारे में क्या? यह एक अन्य टूल / लाइब्रेरी द्वारा तैयार किया गया है और अभी भी परियोजना की बहुत सारी जरूरतों को पूरा करता है।
डेविड

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

1
@ जोर्डन, वे सभी उपकरण बहुत विशिष्ट हैं (और बदतर - पाठ - आधारित, यानी, डिजाइन से हीन)। मैं इसके बजाय उचित मेटाप्रोग्रामिंग के बारे में बात कर रहा हूं।
तर्क

1
@AtillaOzgur, वे "बहुत अच्छे" हो सकते हैं, सच है। लेकिन वे ईडीएसएल से बेहतर नहीं हैं। स्टैंडअलोन कोड पीढ़ी स्पष्ट रूप से बहुत अधिक सीमित है और मैक्रो मेटाप्रोग्रामिंग की तुलना में बहुत कम लचीला है।
SK-तर्क

16

क्लासिक उदाहरणों में से एक लेक्स और याक है। उनका प्राथमिक उद्देश्य किसी भी प्रकार के पार्सर लिखने के नशे से बचना है। रास्ते के साथ, वे कई नियमों और राज्यों के साथ जटिल पार्सर बनाने के लिए बहुत तेजी से बनाते हैं, और वे लोगों द्वारा अपने स्वयं के रोल करने से होने वाली सभी आश्चर्यजनक गलतियों से भी बचते हैं।

यह c के पीछे का विचार भी है, जो कोडांतरक लिखने का एक उपकरण है। एक ही बात किसी भी उच्च स्तरीय भाषा के लिए जाती है जिसका आप नाम रखते हैं। आपके लिए कोड लिखने वाले टूल के लिए, कुछ सरल प्रतिमान हैं।

एक उचित आईडीई आपकी उंगलियों, स्मार्ट ऑटो समापन और कोड स्निपेट्स पर प्रलेखन प्रदान करके मदद करता है। आईडीई के विभिन्न टेम्प्लेट भी शामिल हैं, इसलिए आपको स्क्रैच से एक कार्यक्रम शुरू करने की आवश्यकता नहीं है। एक उच्च स्तर की भाषा में एक uml आरेख और किसी न किसी बाहर कक्षाएं लेने के लिए कार्यक्रम हैं।

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

एक अर्थ में, आप बाइनरी परत के ऊपर जो कुछ भी करते हैं वह कोड ऑटोमेशन है।


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

1
@Jose Faeti विकिपीडिया लेख en.wikipedia.org/wiki/Automatic_programming में विभिन्न विभिन्न उपकरणों के लिंक हैं, यदि आपकी रुचि कुछ और विवरणों में है। मैं lex और yacc पर पढ़ने का सुझाव भी दूंगा, क्योंकि उन लोगों के लिए काफी अधिक प्रलेखन और विवरण है।
स्पेंसर रथबुन

पर्याप्त रूप से शक्तिशाली भाषाओं में (जैसे C ++ C के विपरीत), बाहरी उपकरण जैसे lex और yacc अनावश्यक हैं।
केविन क्लाइन

YACC "किसी भी प्रकार के पार्सर" को नहीं लिखता है। यह एक विशिष्ट प्रकार का पार्सर (LALR) लिखता है जो बिना स्वचालित मदद के सही होना बहुत मुश्किल है। एक अन्य प्रकार का पार्सर (पुनरावर्ती वंश) है जो लिखने और सही होने में बहुत आसान है, और जो कुछ भी हो रहा है उसे पढ़ने और समझने में आसान है।
मेसन व्हीलर

@MasonWheeler एक व्यापक, गैर-सटीक अर्थों में समस्याओं को हल करने के लिए बनाए जा सकने वाले व्याकरणों का जिक्र पार्सर का था। एक साल बाद इसे पढ़ना, यह उतना स्पष्ट नहीं है जितना मुझे पसंद होगा। मुझे यकीन नहीं है कि मैं एलएल (*) पार्सर्स पर लिखने और उपयोग करने में आसान होने के बावजूद आपसे सहमत हूं।
स्पेन्सर रथबुन

13

Metaprogramming

कई दुकानों में मेटाप्रोग्रामिंग एक विवादास्पद तकनीक है। कारण, किसी भी शक्तिशाली उपकरण की तरह, मदद या चोट का परिमाण बड़ा है।

पेशेवरों

  • अधिक अभिव्यंजक, लिखने और बनाए रखने के लिए कम कोड (अक्सर परिमाण या अधिक के क्रम से)
  • संगति, समस्याओं का वर्ग पर अधिक सुसंगत व्यवहार जो आपके कोड के साथ हल हो रहा है
  • उत्पादकता, एक बड़ी समस्या के समाधान के लिए कम कोड

विपक्ष

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

मैं मेटाप्रोग्रामिंग का बहुत बड़ा प्रशंसक हूं, लेकिन मैं इसे लंबे समय से कर रहा हूं। मेरे लिए कम कोड आकार के ट्रेडऑफ़ और जोखिमों के लिए लगातार व्यवहार से अधिक है। कम कोड का मतलब है कम कीड़े, बनाए रखने के लिए कम कोड, और मैं आमतौर पर बहुत तेज़ी से कार्यक्षमता के बड़े टुकड़े जोड़ सकता हूं।

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


उपयोगी विचारों के लिए धन्यवाद! क्या आप मुझे एक बहुत ही सरल और बुनियादी कार्य सुझा सकते हैं जिसे मैं मेटाप्रोग्रामिंग का उपयोग करके कार्यान्वित कर पाऊंगा, जो मुझे सामान्य कोडिंग, थोड़ा कोड उदाहरण से अधिक समय बचाएगा?
जोस फ़ेती

haha मुझे एक त्रुटि के रीमाइबर बनाते हैं जो मैंने जीसीसी के साथ वर्षों पहले किया था। मेरी स्क्रीन पर त्रुटि संदेश डालने के लिए 162 लाइनें। पुनरावर्ती मेटाप्रोग्रामिंग FTW!
deadalnix

6
मेटाप्रोग्रामिंग की जटिलता बहुत अधिक है। जब तक आप सही उपकरणों का उपयोग कर रहे हैं, तब तक इसमें कुछ भी जटिल नहीं है। और डीएसएल विशिष्ट बॉयलरप्लेट कोड की तुलना में डिबग और रखरखाव के लिए बहुत आसान है। इसके अलावा, मैं यह नहीं समझ सकता कि किसी को टाइप सेफ्टी का त्याग क्यों करना चाहिए - यह बिल्कुल विपरीत है, डीएसएल में डोमेन-विशिष्ट, अत्यधिक कुशल टाइप सिस्टम भी हो सकते हैं।
एसके-तर्क

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

@ दिदिबुद्ध, क्या आप कृपया विस्तृत रूप से बता सकते हैं, कि कोई भी अपने स्वयं के DSL की सुरक्षा के लिए किसी भी प्रकार का बलिदान क्यों नहीं कर सकता है, चाहे वह कैसे लागू हो? आप एक शुद्ध प्रकार की प्रणाली के साथ शुद्ध सी में एक तदर्थ दुभाषिया लिख ​​सकते हैं (उदाहरण के लिए हग्स देखें)। आप एक कोड जनरेटर टारगेटिंग C लिख सकते हैं, जो सभी टाइपकास्टिंग स्वयं करता है, लक्ष्य भाषा प्रकार प्रणाली पर निर्भर नहीं है। जटिलता के लिए: अधिकांश लोग इसे अनावश्यक रूप से जटिल तरीके से कर रहे हैं, जबकि सभी समान डिजाइन पद्धति को कोड पीढ़ी में "सामान्य" प्रोग्रामिंग के रूप में लागू किया जा सकता है। लगभग किसी नए ज्ञान की आवश्यकता नहीं है।
तर्क

9

अधिकांश कोड कोड लिखते हैं। उदाहरण के लिए php कोड html लिखने में मदद करता है। Php pdo लाइब्रेरी SQL कॉल लिखने में मदद करती है। फ़ाइल I / O फ़ंक्शन ओएस के साथ संवाद करने के लिए कोड लिखते हैं। यहां तक ​​कि एक नियमित फ़ंक्शन कॉल कोड के किसी अन्य ब्लॉक का संदर्भ है जिसे निष्पादित किया जाता है। इसलिए आपके फ़ंक्शन कॉल कोड लिख रहे हैं।

व्यापक शब्दों में, हम कोड लिखने के रूप में कंप्यूटिंग के बारे में सोच सकते हैं जो कोड लिखता है कोड को एक स्टैक का निर्माण करता है जो तब समाप्त होता है जब यह हार्डवेयर में वायर्ड कोड की भौतिक वास्तविकता के खिलाफ चलता है।


3
मैं html को प्रोग्रामिंग भाषा नहीं कहूँगा। यह दस्तावेजों के लिए एक वाक्यविन्यास है
साइमन बर्गोट

3
@Simon एक दिलचस्प बिंदु है। हमारे द्वारा उपयोग किए जाने वाले विभिन्न कोडों के लिए सभी प्रकार की अभिव्यंजक शक्तियां हैं। कोड एक कमजोर भाषा, एक मजबूत भाषा या अपनी भाषा को लिख सकता है।
बेन हेली

5

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

मेरी अंतिम परियोजना इसमें शामिल थी कुछ बुनियादी ASP.NET CRUD स्क्रीन (कोड पीढ़ी इसके लिए अच्छी है)। प्रक्रिया xml फ़ाइलों में मेटाडेटा के रूप में संस्थाओं को परिभाषित करती है। आवश्यक विभिन्न कलाकृतियों को कवर करने के लिए टेम्प्लेट लिखें (इकाई वर्ग, रिपॉजिटरी, सर्विस क्लास, asp.net नियंत्रण, asp.net पेज आदि)। जेनरेशन प्रोसेस को रन करें और आउटपुट को स्टाइल करें।

टेम्प्लेट लिखने में कुछ ओवरहेड है लेकिन बाद के समान प्रोजेक्ट्स के लिए उनका पुन: उपयोग किया जा सकता है। इसी प्रकार अंतर्निहित डेटा में परिवर्तन मेटाडेटा को बदलकर और पुन: उपयोग करने वाली पीढ़ी को परिवर्तन करके सरल और त्वरित रूप से कार्यान्वित करने के लिए नियंत्रित किया जाता है।

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


5

हमारी कंपनी में हम कुछ उपकरण का उपयोग करते हैं जो वास्तव में इंटरनेट से डाउनलोड किए गए डेटा के साथ सी ++ या सी # कक्षाएं उत्पन्न करते हैं। ये वर्ग डेटा कंटेनर होते हैं और सूचियों में बड़ी संख्या में ऑब्जेक्ट होते हैं।


कुछ आईडीई में पाए जाने वाले कोड स्निपेट जैसे कुछ उदाहरण के लिए विजुअल स्टूडियो जैसे हैं?
जोस फेटी

@Jose हमारा टूल HTML आउटपुट को क्लास में बदलने के लिए सिर्फ एक एप्लीकेशन है। इसलिए हर बार एप्लिकेशन डाउनलोड करने के बाद हम इसे डाउनलोड करने के बजाय इसे एक बार डाउनलोड करते हैं और एक कक्षा बनाते हैं।
होली

5

मेटाप्रोग्रामिंग लंबे समय से प्रोग्रामिंग का हिस्सा रहा है। केवल SWIG, या WYSIWYG डिज़ाइनर्स जैसे टूल पर विचार न करें, जो कोड बनाते हैं, लेकिन C के प्रीप्रोसेसर, या यहाँ तक कि C ++ के टेम्प्लेट और C # / Java के जेनरिक जैसे- इन-लैंग्वेज टूल्स- रिफ्लेक्शन का उल्लेख नहीं करते।

वास्तव में, आप यह तर्क दे सकते हैं कि प्रत्येक संकलक सिर्फ एक और मेट्रोपग्राम है- वे प्रोग्राम टेक्स्ट और आउटपुट मशीन या वीएम कोड में लेते हैं। और, संकलक के बिना जीवन? Owch।


यह सही है, लेकिन आप वास्तव में अपनी प्रोग्रामिंग भाषा में इसे कैसे लागू कर सकते हैं ताकि वास्तव में आपकी उत्पादकता बढ़ सके? वही मुझे याद आ रहा है।
जोस फेटी

5

यहाँ मेरे अतीत से एक ठोस उदाहरण है।

मैं एक ऐसी साइट पर काम कर रहा था जिसमें डेटा एक्सेस के लिए BDE का उपयोग करके लगभग 50MB डेल्फी सोर्स कोड था। वे BDE (8i अगर मुझे सही तरीके से याद है) द्वारा समर्थित उच्चतम संस्करण के पिछले एक Oracle उन्नयन की अनुमति देने के लिए डायरेक्ट ओरेकल एक्सेस का उपयोग करने के लिए स्विच करना चाहते थे।

इसलिए, कोडर्स की एक टीम को हर फॉर्म और डेटा मॉड्यूल के माध्यम से काम करने के लिए हर घटक को मैन्युअल रूप से बदलने के बजाय मैंने एक पर्ल स्क्रिप्ट लिखी है: -

  1. DFM (फॉर्म फाइल) को पार्स किया और एक सूची में सभी वस्तुओं को संग्रहीत करते हुए TQuery, TTable, TStoredProcedure & TDatabase वस्तुओं की पहचान की।

  2. PAS (कोड) को पार्स किया और वस्तुओं के उपयोग की पहचान की - क्या TQueries अपडेट या चयन कर रहे थे? इसके अलावा, इसने IDE में एक फॉर्म पर गिराए जाने के बजाय कोड में बनाई गई किसी भी ऑब्जेक्ट की पहचान की।

  3. DFM और PAS को उचित प्रकार से बदलकर ऑब्जेक्ट टाइप करें (जैसे TTable -> ToracleDataSet को SQL प्रॉपर्टी के साथ "से" का चयन करने के लिए सेट "आदि) और विधि कॉल। मापदंडों को बंद, खोलने और सेट करने के लिए उपयुक्त होने पर, अतिरिक्त विधि कॉल को जोड़ा गया था।

संक्षेप में, 3 सप्ताह 5 महीने के लिए काम करने वाले 5+ डेवलपर्स के मूल अनुमान के बजाय विभिन्न कोडिंग शैलियों के साथ अलग-अलग टीमों द्वारा लिखित विभिन्न अनुप्रयोगों पर काम करने के लिए स्क्रिप्ट को ट्वीक करने का काम करते हैं।

और जिस कारण से मैंने उस दृष्टिकोण का उपयोग करने के बारे में सोचा, वह द प्रोगैमैटिक प्रोग्रामर पढ़ने के माध्यम से था


यह बहुत अच्छा है, मैं अब कुछ दिनों से पर्ल में हूँ और मैंने पहले से ही "वर्कस्पेस बनाने" टाइप करके सभी डाइरेक्टरीज़, वेब डेवलपमेंट के लिए बेसिक वर्कस्पेस बनाने के लिए कुछ प्रोडक्टिविटी टूल बना लिए हैं! :)
जोस फ़ेती

1
@ यह विचार है। दोहराव वाले सामान को स्वचालित करने के लिए स्क्रिप्टिंग भाषाओं का उपयोग करें। यह एक बार के लिए हो सकता है जहां आपको 8x उत्पादकता में वृद्धि मिलती है या आपके मामले में कुछ समय लगता है कि आप बार-बार करेंगे।
mcottle

4

आप उदाहरण के लिए पूछें ....

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

उदाहरण के लिए, DATE डेटा-प्रकार को MS SQl सर्वर में पेश किए जाने से पहले, डेट कॉलम के लिए एकमात्र विकल्प DATETIME था जिसमें एक समय भाग होता है - एक समय हिस्सा जो डेटा के साथ थोड़ा कठिन काम करता है। दिनांक डेटा-प्रकार के साथ एक संस्करण में अपग्रेड करने पर, आप उन स्तंभों को अपडेट करना चाह सकते हैं जहां समय हमेशा 00:00 है। दर्जनों या सैकड़ों डेटाइम कॉलम वाले डेटाबेस में यह काफी समय लेने वाला होगा। लेकिन एक पटकथा लिखना आसान है जो सभी तालिकाओं पर सवाल उठाता है, डेटा कॉलम के साथ हर कॉलम की जांच करके यह देखने के लिए कि क्या यह समय कभी भी है, लेकिन 00:00 है और यदि तालिका / स्तंभ को बदलने के लिए कोई कथन नहीं बनाया गया है डेटा प्रकार DATE को। प्रेस्टो, कोड जो कोड लिखता है।


3

सीएल (कॉमन लिप्स) मैक्रोज़ पर एक नज़र डालें। मेरी राय में वही है जो आप चाहते हैं। मेटाप्रोग्रामिंग में होंठ एकदम सही होते हैं।

इसके अलावा, अगर आप चाहते हैं कि मैं नेमारल को सुझाव दूं कि आपके पास सही मेटाप्रोग्रामिंग समर्थन (मैक्रोज़ सहित) के साथ .NET शक्तियां हैं

लेकिन अगर आप एक सच्चा कोड-जनरेशन इंजन चाहते हैं तो अपाचे थ्रिफ्ट पर एक नज़र डालें


3

मैं सिर्फ ऐसे टूल पर काम कर रहा हूं। हमारे विशेष मामले में हम डेटाबेस में फ़ंक्शंस के हस्ताक्षरों पर डेटा लेयर के आधार पर VB.NET कोड जनरेट करते हैं।

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

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

मेरी ईमानदारी से सिफारिश है कि अगर आपको लगता है कि आप दोहराव वाले तरीके से कोड लिखते हैं , और आप समय बिता सकते हैं .. तो सोचने की कोशिश करें कि क्या आप जो कर रहे हैं वह उत्पन्न कोड द्वारा नहीं किया जा सकता है। और यदि ऐसा है (यदि यह दोहराए जाने वाले कोड की तुलना में लगभग हमेशा मामला है) तो सोचें कि आपको कितनी बार विस्तार करना होगा, उस कोड को थोड़ा संशोधित करें और यह भी कि आपको उस सटीक कोड को कितनी बार लिखना है। यदि इनमें से किसी का उत्तर "कई" है, तो आपको उस कोड के लिए एक जनरेटर बनाने पर गंभीरता से विचार करना चाहिए

आशा है कि मदद करता है,
IPP


उत्तर के लिए धन्यवाद! आपके उदाहरण में नियम वास्तव में कैसे लागू किए गए हैं?
जोस फ़ेती

1
मैं आपको सभी नियम नहीं बता सकता, लेकिन मैं आपको कुछ उदाहरण दे सकता हूं। हम एक ओरेकल डेटाबेस द्वारा उजागर किए गए इंटरफ़ेस को पार्स करते हैं और हम ऑर्कल इंटरफ़ेस में फ़ंक्शन के हस्ताक्षर को ध्यान में रखते हैं। हस्ताक्षर के आधार पर हम डेटा लेयर फ़ंक्शन का नाम जनरेट करते हैं। हम जानते हैं कि हम हमेशा db से एक ओरेकल डेटा टेबल प्राप्त करते हैं, जिसके परिणामस्वरूप हम अपने डेटा को स्टोर करने के लिए उपयोग की जाने वाली विशेष ऑब्जेक्ट प्रकार की एक सरणी में सहेजते हैं। इसके अलावा, db फ़ंक्शन सिग्नेचर के इनपुट / आउटपुट पैरामीटर्स के आधार पर हम अपने द्वारा उत्पन्न फंक्शन्स और इसी तरह के इनपुट और आउटपुट पैरामीटर्स को जोड़ते हैं ..
Ioan Paul Pirau

3

मेरे पास एक PHP मॉड्यूल है जो जावास्क्रिप्ट कोड वाले एक वेब पेज को आउटपुट करता है जो HTML उत्पन्न करता है। वहीं तीन परतें हैं। लड़का पढ़ना मुश्किल था!

एक प्रोग्रामिंग क्लास में, हमें एक प्रोग्राम लिखना था जो उपयोगकर्ता से एक सूत्र स्ट्रिंग लेगा और इसे पार्स करेगा और मूल्य प्रदर्शित करेगा। सबसे प्रभावशाली सॉल्वर ने केवल उपयोगकर्ता इनपुट लिया, इसे मुख्य () {printf ("% d", ...);} में लपेटा और स्क्रिप्ट को संकलित करने, लिंक करने और चलाने के लिए चलाया। उन्होंने एक पार्सर नहीं लिखा! आज आप एक SQL चयन कथन में ऐसा कर सकते हैं।

यह एक उपकरण है जिसे आपको खेलना चाहिए, फिर इसे भविष्य के किसी दिन के लिए स्टोर करें जब यह काम में आएगा।


यह वास्तव में वही चीज है जिसे मैं लागू करने की कोशिश कर रहा था! :) लेकिन फिर मैंने इसे पर्ल ऑफ़लाइन के साथ कोड करने का फैसला किया और यह बहुत अच्छा काम कर रहा है। मैं सुविधाओं की एक टन है मैं जोड़ने के लिए सोच रहा हूँ!
जोस फेटी

मैं भाषा की 20 परतों तक भाषा परिवर्तनों के साथ कोड लिख रहा हूं, जिसमें कोई समस्या नहीं है। यह 20 परतों की कॉल स्टैक गहराई होने से अधिक जटिल नहीं है। इसलिए मैं दृढ़ता से असहमत हूं कि यह " भविष्य के कुछ दिनों के लिए इसे स्टोर करना है जब यह आसान होगा " एक उपकरण है - कोड पीढ़ी हमेशा काम करती है।
तर्क

3

मैंने प्रोलॉग के साथ नीट मेटा-प्रोग्रामिंग समाधान विकसित किए हैं । जहां मुख्य एप्लिकेशन (C ++ में) रनओवर में प्रॉब्लम एप्लिकेशन में एक समस्या की एक अमूर्त परिभाषा का अनुवाद करता है, जिसे बाद में सौंप दिया जाता है। अक्सर C ++ में बराबर कार्यक्षमता लिखना हमेशा के लिए ले जाएगा।

मुझे लगता है कि यह परिदृश्य कोड-राइटिंग-कोड तर्क के पक्ष में एक उत्कृष्ट मामला है ।


3

आप विषय के बारे में क्या सोचते हैं?

Metaprogramming सबसे अधिक गैर-गतिशील भाषाओं से जुड़ी होती है, क्योंकि कोड के बहुत सारे गैर-उत्पादक और गैर-बुद्धिमान लाइनों के बिना कुछ व्यवहार (जैसे ORM लागू करना) प्राप्त करने में कठिन समय होता है।

लेकिन यहां तक ​​कि अधिक गतिशील भाषाओं जैसे कि PHP में, कोड पीढ़ी वास्तव में जीवन रक्षक हो सकती है और बड़े पैमाने पर उत्पादकता बढ़ा सकती है। आधुनिक ढाँचों में मचान का होना बहुत आम बात है जो एक निश्चित व्यावसायिक वस्तु के लिए अधिकांश सामान्य मॉडल, रूप, परीक्षण और कार्यों को उत्पन्न करता है जिसे आप घोषित करते हैं। यह उन कारणों में से एक है कि फ्रेमवर्क जैसे कि सिम्फनी या आरओआर को इतनी सफलता क्यों मिली है, कोड-जनरेशन टूल लगातार कोड को बहुत जल्दी बनाते हैं और प्रोग्रामर उत्पादकता को बढ़ावा देते हैं।

वेब-साइटों में, अधिकांश इंटरैक्शन चार मुख्य क्रियाओं के आसपास घूमता है:

  • एक तत्व बनाएँ
  • तत्वों का एक सेट प्राप्त करें (संभव फ़िल्टरिंग के साथ)
  • नई विशेषताओं के साथ एक तत्व को अपडेट करें
  • तत्वों का एक सेट हटाएं

कम से कम सब कुछ जो इस 4 मुख्य क्रियाओं के इर्द-गिर्द घूमता है और अधिकतम उत्पादकता प्राप्त करने के लिए कोड-जेनरेशन टूल्स का उपयोग करके IMHO SHOULD प्राप्त किया जा सकता है।

मेरी कंपनी में, हम सिम्फनी का उपयोग करते हैं, और इसका व्यवस्थापक-जनरेटर एक असाधारण उपकरण है, जो रन-टाइम में कोड भी बनाता है (और इसे कैश करता है), जिसका अर्थ है कि हमें किसी भी प्रकार के कार्य या बाहरी टूल का उपयोग करने की आवश्यकता नहीं है नया कोड जनरेट करें, हमें बस अपना कैश साफ़ करना होगा। मैं CRUD संचालन के लिए इस तरह के उपकरण का उपयोग करने की सलाह देता हूं।

लेकिन, सिम्फनी भयानक योगदानकर्ताओं ने जो किया, वह करना आसान काम नहीं है। मैंने कुछ कोड-जनरेशन कार्यों को स्वयं कार्यान्वित किया है और कुछ ऐसा करना है जो वास्तव में सुसंगत है और अधिकांश कोने-मामलों को कवर करने के लिए व्यापक कार्यान्वयन के साथ आसान नहीं है।

क्या यह कुछ ऐसा है जो वास्तव में आपकी उत्पादकता बढ़ाएगा?

मेरा मानना ​​है कि कार्य के निचले-स्तरों (चौखटे, कैशिंग, संकलक, आदि) में मेटाप्रोग्रामिंग बहुत महत्वपूर्ण है, लेकिन कुछ ऐसा जो हमें अत्यधिक सावधानी के साथ करना चाहिए यदि हम व्यवसाय-परत पर काम कर रहे हैं।

कोड-पीढ़ी का उपयोग करना किसी भी प्रश्न के बिना एक प्रमुख उत्पादकता-बूस्टर है। अपने स्वयं के कोड-पीढ़ी के उपकरणों को लागू करना, तब तक नहीं जब तक आप स्वयं एक रूपरेखा का निर्माण नहीं कर रहे हों।

पुस्तकों, ब्लॉगों, स्लाइडशो, आदि के बीच इस विषय पर कुछ अच्छे संसाधन क्या हैं?

प्रोग्रामिंग को समझने के लिए सबसे अच्छा संसाधन हमेशा अच्छा और अच्छी तरह से टिप्पणी की गई स्रोत कोड है। मैं कहूंगा कि RubyOnRails और सिम्फनी व्यवस्थापक जनरेटर को देखना एक अच्छा विचार है।


3

जबकि यहाँ कई उत्तर यह संदर्भित करते हैं कि आमतौर पर मेटा प्रोग्रामिंग के रूप में जाना जाता है, वास्तव में एआई से जुड़ा एक क्षेत्र था जिसे स्वचालित प्रोग्रामिंग के रूप में जाना जाता था जो कार्यक्रमों को समझने या संश्लेषित करने वाले कार्यक्रमों के बारे में था [1]।

कोई भी कंपाइलर (या मेटा-प्रोग्राम, कोड जनरेटर, ट्रांसलेटर, मैक्रो सिस्टम, ...) ट्रांसफॉर्मेशन के साथ काम करता है, ट्रांसफॉर्मेशन के अपने निश्चित एल्गोरिदम को ले जाकर एक इनपुट से एक आउटपुट जेनरेट करता है। लेकिन एक पारंपरिक संकलक या मेटा-प्रोग्राम एक सूची को छाँटने की परिभाषा, विवरण या उदाहरण नहीं देता है (उदाहरण। [5, 3, 9] => [3,5,9]), एक छँटाई एल्गोरिथ्म बनाएँ। ऐसी समस्याएं जहां इस "स्वचालित प्रोग्रामिंग" क्षेत्र के हित हैं।

[१] - कार्यक्रम-समझ प्रणालियों पर प्रगति रिपोर्ट http://db.stanford.edu/pub/cstr/reports/cs/..///CS-TR-74-444.pdfShare


2

मेटा प्रोग्रामिंग को बनाए रखना बहुत मुश्किल हो सकता है। पहले तो यह सुरुचिपूर्ण दिखता है, लेकिन जब आप कोने के मामलों में भागना शुरू करते हैं, तो त्रुटियों को देर से पकड़ा जाता है (उत्पन्न होने वाले कोड पर), और पूरी बात उपयोग / डिबग के लिए दुःस्वप्न बन जाती है।

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


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

मुझे अजगर एएसटी के बारे में आपकी बात में दिलचस्पी है। क्या आपने मेटा प्रोग्रामिंग उद्देश्य के लिए टेम्पपिटा का उपयोग किया है?
साइमन बर्गोट

यह ( docs.python.org/library/ast.html ) काफी तदर्थ एएसटी है, और पार्सर एक अडॉप्टेड, ओवरब्लोएटेड ट्री देता है, जो एक विश्लेषण समस्याग्रस्त बनाता है (विशेष रूप से पाइरॉन में मेल खाते उचित पैटर्न की कमी के साथ)। ऐसे एएसटी का निर्माण करना बहुत सुविधाजनक नहीं है। मैंने पायथन और सी कोड (यानी, शुद्ध पाठ-आधारित मेटाप्रोग्रामिंग) दोनों के उत्पादन के लिए टेंपिटा का इस्तेमाल किया, यह उस विशिष्ट कार्य (बॉयलरप्लेट कोड पीढ़ी) के लिए ठीक काम किया। मैंने कुछ XML उच्च स्तरीय विवरणों में से C कोड उत्पन्न करने के लिए अक्सर पायथन का उपयोग किया।
SK-Logic

2

ओपी संसाधन मांगता है।

आपको हमारी डीएमएस सॉफ्टवेयर रीइंजीनियरिंग टूलकिट दिलचस्प लग सकती है। यह एक शुद्ध मेटाप्रोग्रामिंग उपकरण है, जिसका उद्देश्य किसी कस्टम प्रोग्राम विश्लेषण और परिवर्तन उपकरण का निर्माण करना है।

[ओपी के सवाल के लिए एक टिप्पणी का पालन करने के लिए, जब एक विशिष्ट परिवर्तन उपकरण बनाने के लिए उपयोग किया जाता है, डीएमएस एक उत्पाद लाइन है जो कोड लिखती है, जो लिखते हैं:]

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

और एक OS की तरह, DMS को बहुत कम राय या अड़चन के लिए डिज़ाइन किया गया है कि आप क्या (मेटा) प्रोग्राम लिखना चाहते हैं, जिसका अर्थ है कि इसका उपयोग विभिन्न प्रकार के उद्देश्यों के लिए किया जा सकता है: मैट्रिक्स निकालना, मृत कोड ढूंढना, पहलू बुनकर लागू करना, अनुवाद करना langauges, DSLs से कोड जेनरेट करते हुए, बड़े अनुप्रयोगों की खोज करते हैं। (इन सभी कार्यों के लिए डीएमएस का उपयोग पहले ही किया जा चुका है)।

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


2

देखें एमआईटी कोर्स 6.916 से फिलिप ग्रीन्सपुन की समस्या सेट: इनोवेटिव वेब सर्विसेज की सॉफ्टवेयर इंजीनियरिंग ( http://philip.greenspun.com/teaching/psets/ps4/ps4.adp )।

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

यह समस्या के संभावित सेटों में से एक है। ArsDigita ( http://en.wikipedia.org/wiki/ArsDigita ) रंगरूटों को पहले बुलबुले के दौरान हल करना आवश्यक था।

Pset में "SQL for Web Nerds" बुक फिलिप संदर्भ को स्थानांतरित कर दिया गया है ( http://philip.greenspun.com/sql/ )।


2

2001 में या उसके आसपास मैंने एक ऐसी परियोजना पर काम करना शुरू कर दिया, जो व्यापारिक वस्तुओं और डेटा ऑब्जेक्ट का व्यापक उपयोग कर रही थी। मुझे फ्रंट-एंड वेबसाइट का निर्माण करना था, लेकिन मेरे अंगूठे को मोड़ दिया गया था क्योंकि व्यावसायिक परत और डेटा एक्सेस परत पूरी तरह से विकसित नहीं हुई थी। कुछ हफ़्ते के बाद, मैं उन परतों पर क्या कर रहा था, इस पर कड़ी नज़र रखना शुरू कर दिया। मूल रूप से, वे संग्रहीत प्रक्रियाओं से लौटाए गए डेटा को डेटा में फ़ील्ड्स के अनुरूप गुणों के साथ वस्तुओं के संग्रह के रूप में प्रदर्शित कर रहे थे, या इनपुट मापदंडों को ले रहे थे और उन्हें संग्रहीत कार्यविधियों को डेटाबेस तालिकाओं में सहेजने के लिए भेज रहे थे। दोनों परतों के बीच बहुत सीरियलाइज़ेशन / डिसरलाइज़ेशन हो रहा था, इसमें Microsoft Transaction Server शामिल था, एक IDL / ODL प्रकार की लाइब्रेरी ... लेकिन यह सभी एक पैटर्न फिट है।

2 सप्ताह बाद, मेरे पास एक कोड जनरेटर था, जिसने आईडीएल / ओडीएल को बाहर निकाल दिया, और व्यापार और डेटा वस्तुओं को भी बाहर निकाल दिया। यह 2 साल के व्यापार और डेटा लेयर ऑब्जेक्ट्स का निर्माण करने वाले व्यक्ति को इन ऑब्जेक्ट्स को डीबगिंग और परीक्षण करने के लिए ले गया था। 2 सप्ताह में, कोड पीढ़ी के साथ, हमारे पास एक ही आउटपुट था, लेकिन क्योंकि यह सब उत्पन्न हुआ था, यह बहुत अच्छी तरह से बग-मुक्त था।

उस कोड जनरेटर (निचले स्तर के CASE उपकरण) ने लगभग 8 से 10 वर्षों तक कई अलग-अलग पुनरावृत्तियों के माध्यम से मेरा पीछा किया, क्योंकि सिद्धांत सिर्फ इतना सरल था: आप कुछ कर रहे हैं जो डेटाबेस से बात करते समय किए जाने की आवश्यकता है, यह सुंदर है बहुत दोहरावदार कोडिंग, और एक बार जब आप इसे सही कर लेते हैं तो आपको इसके साथ कोई चिंता करने की ज़रूरत नहीं है।

तो, हाँ: एक कोड जनरेटर का उपयोग करें, खासकर जब कोडिंग दोहरावदार हो और एक अच्छी तरह से परिभाषित पैटर्न फिट बैठता है।

मुझे पता है कि लोग इसी तरह की चीजें करने के लिए RegX मैक्रोज़ का उपयोग करते हैं, या इसी तरह की चीज़ों को करने के लिए एक्सेल फ़ार्मुलों का उपयोग करते हैं (मैं यह भी करता हूं)।


2

एक मेटाप्रोग्रामिंग उदाहरण

मेरे पास एक रूबी प्राधिकरण पुस्तकालय है जिसे प्राधिकरण कहा जाता है । यह डेवलपर्स को उनके ऐप में current_user.can_read?(@post)और जैसे तरीकों से सवाल पूछने देता है @post.readable_by?(current_user)। इन सवालों का जवाब केंद्रीकृत लेखक वर्गों द्वारा दिया जाता है।

यह महत्वपूर्ण हिस्सा है: प्राधिकरण को पता नहीं है कि उपयोगकर्ता के कॉन्फ़िगरेशन को देखने तक कौन से तरीके परिभाषित करने हैं । उपयोगकर्ता कॉन्फ़िगरेशन में हो सकता है:

config.abilities =  {
  ...
  :read      => 'readable',
  :microwave => 'microwavable',  # user-defined
  ...
}

उस मामले में, एक विधि की तरह होना चाहिए current_user.can_microwave?(@post)

Metaprogramming इसे संभव बनाती है: कॉन्फ़िगरेशन पढ़ने के बाद, मुझे पता है कि किन तरीकों को परिभाषित करना है :

Authority.verbs.each do |verb|
  class_eval <<-RUBY, __FILE__, __LINE__ + 1 # allows for a nice bracktrace
    def can_#{verb}?(resource)
      resource.#{Authority.abilities[verb]}_by?(self)
    end
  RUBY
end
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.