क्लोजर में, हेटरोजेनस नोड प्रकार के पेड़ों को रिकॉर्ड या वैक्टरों का उपयोग करके कब प्रदर्शित किया जाना चाहिए?

Question

अलग नोड प्रकार से बना एक पेड़ का प्रतिनिधित्व करने के लिए बेहतर मुहावरेदार clojure अभ्यास है कौन सा:

ए इमारत रिकॉर्ड के कई अलग अलग प्रकार के बाहर पेड़, कि एक deftype या defrecord का उपयोग कर परिभाषित करता है:

(defrecord node_a [left right]) 
(defrecord node_b [left right]) 
(defrecord leaf []) 

(def my-tree (node_a. (node_b. (leaf.) (leaf.)) (leaf.))) 

वैक्टर से बाहर बी इमारत के पेड़, कीवर्ड प्रकार तय किया साथ:

(def my-tree [:node-a [:node-b :leaf :leaf] :leaf]) 

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

हमें दूसरी शैली में एक शैली को कब पसंद करना चाहिए?

Answer 1

आप जितना चाहें वेक्टर में जितने तत्व डाल सकते हैं। एक रिकॉर्ड में फ़ील्ड की एक निश्चित संख्या है। यदि आप अपने नोड्स को केवल एन उप-नोड्स में रखना चाहते हैं, तो रिकॉर्ड अच्छा हो सकता है, उदा। जब एक बाइनरी पेड़ बनाते हैं, जहां एक नोड के पास केवल एक बाएं और दाएं होते हैं। लेकिन एचटीएमएल या एक्सएमएल जैसे कुछ के लिए, आप शायद उप-नोड्स की मनमानी संख्याओं का समर्थन करना चाहते हैं।

वैक्टर और कीवर्ड का उपयोग करने का अर्थ है कि समर्थित नोड प्रकारों के सेट को "विस्तारित करना" एक नया कीवर्ड वेक्टर में डालने जैसा आसान है। [:frob "foo"] हिचकप में ठीक है भले ही उसके लेखक ने कभी भी झुकाव के बारे में सुना न हो। रिकॉर्ड का उपयोग करके, आपको संभावित रूप से प्रत्येक नोड प्रकार के लिए एक नया रिकॉर्ड परिभाषित करना होगा। लेकिन फिर आपको टाइपो को पकड़ने और उपन्यास सत्यापित करने का लाभ मिलता है। [:strnog "some bold text?"] हिचक द्वारा पकड़ा नहीं जा रहा है, लेकिन (Strnog. "foo") एक संकलन-समय त्रुटि होगी।

वेक्टर क्लोजर के मूल डेटा प्रकारों में से एक हैं, आप क्लोजर के अंतर्निर्मित कार्यों का उपयोग उनको कुशल बनाने के लिए कर सकते हैं। अपने पेड़ का विस्तार करना चाहते हैं? बस conj पर, या update-in, या जो भी हो। आप अपने पेड़ को इस तरह से बढ़ा सकते हैं। रिकॉर्ड के साथ, आप शायद कन्स्ट्रक्टर कॉल के साथ फंस गए हैं, अन्यथा आपको रचनाकारों के लिए रैपर फ़ंक्शन का एक टन लिखना होगा।

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

Answer 2

यह एक अच्छा सवाल है। मुझे लगता है कि दोनों अलग-अलग प्रकार की समस्याओं के लिए उपयुक्त हैं। नेस्टेड वेक्टर एक अच्छा समाधान हैं यदि प्रत्येक नोड में जानकारी का एक चर सेट हो सकता है - विशेष रूप से टेम्पलेटिंग सिस्टम अच्छी तरह से काम करने जा रहे हैं। रिकॉर्ड्स फिक्स्ड नोड प्रकारों की एक छोटी संख्या के लिए एक अच्छा समाधान है जहां घोंसले कहीं ज्यादा बाधित होती है।

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

1.2 में रिकॉर्ड्स इम्हो काफी "समाप्त" नहीं हैं, लेकिन यह स्वयं को उस सामान को बनाना बहुत आसान है।हम एक defrecord2 कि निर्माता कार्य (नई-foo), क्षेत्र सत्यापन, प्रिंट समर्थन, pprint समर्थन, ज़िपर के माध्यम से पेड़ की पैदल दूरी पर/संपादन सहायता आदि

जहाँ हम का उपयोग इस ASTs या निष्पादन का प्रतिनिधित्व करने के लिए है का एक उदाहरण कहते है योजनाएं जहां नोड्स, जॉइन, सॉर्ट इत्यादि जैसी चीजें हो सकती हैं

वेक्टर स्ट्रिंग्स जैसी चीजें बनाने के लिए बेहतर होने जा रहे हैं जहां प्रत्येक नोड में मनमाने ढंग से चीजों को रखा जा सकता है। यदि आप 1+ < पी > एस <div> के अंदर सामान कर सकते हैं, तो आप एक रिकॉर्ड नहीं बना सकते जिसमें एक: p फ़ील्ड है - जो कि कोई समझ नहीं लेता है। यह एक ऐसा मामला है जहां वैक्टर बहुत अधिक लचीला और बेवकूफ हैं।