2011-12-22 12 views
22

.NET में विशेषता एक बहुत ही लोकप्रिय विशेषता है। और जावा ने 1.5 के बाद एनोटेशन जोड़ा, एनोटेशन हर जगह उपयोग किया जाता है, जावा ईई और स्प्रिंग देखें। लेकिन कुछ स्कैला पुस्तकालय एनोटेशन का उपयोग करते हैं। लिफ्ट-जेसन इसका उपयोग नहीं करते हैं। लिफ्ट-रिकॉर्ड इसका उपयोग नहीं करते हैं। स्क्वायरल इसका उपयोग नहीं करते हैं। उपकट इसका उपयोग नहीं करते हैं। (इसमें कंपाइलर प्लगइन के लिए एनोटेशन है) ... बस कुछ नाम दिए गए।स्कैला लोगों को एनोटेशन पसंद क्यों नहीं है?

वे केवल कुछ संकलन जादू की आवश्यकता होने पर एनोटेशन का उपयोग करते हैं। @tailrec, @inline, @BeanProperty, @Inject (subcut में) ...

स्कैला में सुपर लचीली प्रकार प्रणाली, विशेषता, निहित और मेनिफेस्ट [एक्स] है। तो उन्हें रनटाइम मेटा-डेटा की आवश्यकता नहीं है?

क्या कोई स्कैला परियोजना एनोटेशन का भारी उपयोग करती है?

पेज। मुझे लगता है कि Dynamic एनोटेशन होना चाहिए लेकिन विशेषता नहीं है।

+2

एनोटेशन के उपयोग की इस झील में क्या व्यावहारिक समस्या है? – Mat

+0

गतिशील एक प्रकार है। यह एक टिप्पणी क्यों होनी चाहिए? – Jan

+0

क्योंकि इसमें कोई विधि नहीं है, और जब आप इसका उपयोग करते हैं, तो आपके पास अपना स्वयं का प्रकार होता है, गतिशील बस आपको बताता है कि आपका प्रकार गतिशील है। – iron9light

उत्तर

27

आम तौर पर, हम एनोटेशन का उपयोग नहीं करते हैं क्योंकि हम वास्तव में को की बहुत सारी चीजों की आवश्यकता नहीं है।

कुछ स्थानों पर मैं एनोटेशन इस्तेमाल किया देखा है

:।।

  • अतिरिक्त प्रकार सिस्टम (जैसे सीमांकित निरंतरता या प्रभाव ट्रैकिंग प्लगइन के लिए सीपीएस प्लगइन
  • विरासत जावा इंटरफेस के साथ Interfacing (scala-mojo-support)
  • प्रवर्तन/संकलक अनुकूलन सक्षम करने @inline या @tailrec की तरह।

स्काला में, हम नहीं वास्तव में एक निर्भरता इंजेक्शन ढांचे की आवश्यकता है, क्योंकि निर्भरता इंजेक्शन के कुछ तरीके हैं जिन्हें बाह्य उपकरण की आवश्यकता नहीं है। आप DI कोड को कोर कोड से अलग कर सकते हैं, लेकिन अभी भी स्कैला में लिखा जा सकता है। देखें: https://github.com/jsuereth/scala-in-depth-source/blob/master/chapter11/src/main/scala/scalax/config/Test.scala

तो मूल उत्तर यह है कि एनोटेशन के साथ कुछ भी गलत नहीं है, हमें केवल उन लोगों की आवश्यकता नहीं है जो अभी भी (अभी तक) हैं।

+0

मुझे लगता है कि सीपीएस के लिए एनोटेशन, @ सीपीएसपाम, एक टाइप कॉन्स्ट्रेन है, पारंपरिक एनोटेशन से अधिक जो केवल रनटाइम मेटा-डेटा प्रदान करता है। – iron9light

+0

यह और भी है कि जावा/सी # से एनोटेट किए जा सकने वाले स्कैला अधिक लचीला है। यह अभी भी एक एनोटेशन है, उसी एएसटी का उपयोग अन्य एनोटेशन के रूप में करता है, लेकिन एक प्रकार पर होता है। जावा एनोटेशन * रन * पर उपलब्ध नहीं हो सकते हैं, लेकिन केवल संकलित/उपयुक्त समय हो सकते हैं। यह एनोटेशन क्लास पर '@ रिटेंशन' सेटिंग के माध्यम से किया जाता है। – jsuereth

2

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

JSON मामले के लिए, परिवर्तन के लिए विकल्प होगा निम्नलिखित: 1. एक समारोह या वर्ग है कि लक्ष्य वर्गों पर अपने JValue 2. प्रतिबिंब पार्स करके बनाता है अपनी कक्षा टी अपने लेआउट और क्या यह निर्धारित करने के वैकल्पिक है, फिर कुछ "गतिशील" कोड जो उस पार्स किए गए डेटा को बनाने के लिए चलाता है और फिर अंततः उचित प्रकार पर डाला जाता है।

12

मेरे लिए यह अक्सर कंपाइलर लागू प्रकार की सुरक्षा का मुद्दा होता है। Squeryl पर एक नज़र डालें और यह जावा ओआरएम से हाइबरनेट जैसे अलग कैसे है। जहां हाइबरनेट एक प्राथमिक कुंजी को इंगित करने के लिए @Id एनोटेशन का उपयोग करेगा, स्क्वायरल में आप एक आईडी सदस्य बनाते हैं, जिसे KeyedEntity विशेषता द्वारा निर्दिष्ट किया गया है। जिन तरीकों को प्राथमिक कुंजी के साथ किसी इकाई की आवश्यकता होती है (उदाहरण के लिए & हटाएं) संकलित समय पर जोर से क्रैश हो जाएंगे यदि किसी को परिभाषित नहीं किया गया है।स्क्वायरल के भीतर कई अन्य स्थान हैं जहां टाइपएफ़ संरचनाएं मैपिंग और डेट/टाइम हैंडलिंग जैसी एनोटेशन को प्रतिस्थापित करती हैं।

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

0

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

उदाहरण के लिए JSON आउटपुट मॉडल करने के लिए एनोटेशन का उपयोग करके देखें: जावा में आपको पता चलेगा कि यह आपके प्रोग्राम को चलाने पर ठीक काम करता है या नहीं। स्कैला में आप टाइप क्लास का उपयोग मॉडल के लिए कर सकते हैं कि जेएसओएन में प्रत्येक प्रकार कैसे व्यक्त किया जाता है। यदि आप एक परिभाषा याद करते हैं, तो संकलन आपको बताएगा। एक उत्कृष्ट उदाहरण spray-json है।

डेव व्हिटकर अपने answer में एक और महान उदाहरण देता है।

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

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