2012-07-28 18 views
8

में लक्षण बनाम पैकेज Martin's keynote on Reflection and Compilers देखने के बाद मुझे अपने सिर से यह पागल सवाल नहीं लग रहा है। मार्टिन "(वेडिंग) केक पैटर्न" के बारे में अन्य चीजों के बीच वार्ता करता है, जहां लक्षण केंद्रीय भाग खेलते हैं। मैं सोच रहा हूं, दुनिया में क्यों हमें पैकेज की जरूरत है जब हमारे पास पहले से ही लक्षण हैं? क्या package कुछ भी कर सकता है, trait (कम से कम सैद्धांतिक रूप से) क्या कर सकता है?स्केल

मैं वर्तमान कार्यान्वयन के बारे में बात नहीं कर रहा हूं, मैं सिर्फ कल्पना करने की कोशिश कर रहा हूं कि यदि हम गुणों के साथ पैकेज को प्रतिस्थापित करते हैं तो प्रोग्रामिंग कैसा होगा। मेरे सिर में इसे इस तरह होगा:

  • एक कीवर्ड कम (package अनावश्यक है)
  • के लिए package object रों

मेरे सभी प्रश्नों संक्षेप करने की कोई जरूरत नहीं:

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

अद्यतन

डैनियल Spiewak this keynote में निर्भरता इंजेक्शन बस सब सामान आप केक पैटर्न के साथ क्या कर सकते हैं हिमशैल के शीर्ष होने के बारे में बात करती है।

+0

यह सिर्फ (स्थिर) [newspeak] (http://newspeaklanguage.org/) है! :) –

उत्तर

7

मार्टिन ओडर्स्की ने कहा है कि स्कैला केवल लक्षणों, वस्तुओं, विधियों और पथों से प्राप्त हो सकता है (मुझे उम्मीद है कि मैं कुछ नहीं भूल गया)।

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

उपरोक्त कथन स्कैला से जेनेरिकों को संभावित रूप से हटाने के बारे में चर्चा में किया गया था, क्योंकि सब कुछ जेनेरिक भी कर सकते हैं, सार तत्वों द्वारा भी हासिल किया जा सकता है।

+0

तो आप कह रहे हैं कि यह वास्तव में सैद्धांतिक रूप से संभव है, लेकिन इसे लागू करने के लायक नहीं होगा, क्योंकि हम में से कोई भी नहीं है यह कल्पना करने में सक्षम है कि यह वास्तव में हमें क्या खरीदता है;) – agilesteel

+0

यह भाषा का एक महत्वपूर्ण सरलीकरण खरीदता है, और चूंकि सादगी एक स्कैला का मुख्य लक्ष्य है, यह निश्चित रूप से समझ में आता है। यह मेजबान मंच इंटरऑपरेबिलिटी खो देगा, हालांकि, स्कैला का एक और मुख्य लक्ष्य है। आप उन सभी मामलों के लिए ऑब्जेक्ट्स का उपयोग कर सकते हैं जहां आप पैकेज का उपयोग करेंगे, लेकिन जावा पैकेज या सीएलआई नेमस्पेस में स्कैला ऑब्जेक्ट्स को मैप करने का कोई साफ तरीका नहीं है। इंटरफेस के साथ स्थिति अलग है: पूरी तरह से अमूर्त लक्षणों और इंटरफेस के बीच एक स्पष्ट मैपिंग है, इसलिए, स्कैला भाषा में उन्हें बिना जावा/सीएलआई इंटरफेस के साथ अंतःक्रिया कर सकती है। –

6

स्केल में ऑब्जेक्ट और पैकेज लगभग एक ही उद्देश्य प्रदान करता है और वस्तुओं को मॉड्यूल भी कहा जाता है। ऑब्जेक्ट्स को मॉड्यूल के रूप में माना जाने योग्य होना चाहिए क्योंकि उनमें पाठ्यक्रम की अन्य वस्तुओं और महत्वपूर्ण रूप से, किसी भी परिभाषा शामिल हो सकती है।

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

  1. मुझे लगता है कि संकुल वस्तुओं (नहीं लक्षण) के पक्ष में हटाया जा सकता:

    अंत में एक जवाब देने के लिए।

  2. लाभ एक सरलीकरण होगा - पैकेज ऑब्जेक्ट्स को स्पष्ट रूप से परिभाषित करने की आवश्यकता नहीं होगी।
  3. मुझे लगता है कि पैकेज जावा/जेवीएम संगतता के लिए ऑब्जेक्ट्स से अलग हैं।

कुछ और टिप्पणी: वीडियो मार्टिन में गुणों (अमूर्त मॉड्यूल) कंक्रीट मॉड्यूल से अधिक की बात है क्योंकि उत्तरार्द्ध केवल अंतिम क्षण में अमूर्त मॉड्यूल के कुछ संयोजन को इकट्ठा करने और सुधारने के लिए दिखाई देता है।

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

+0

"ओटी" क्या है? एक sidenote के रूप में, एक अच्छा '???' फ़ंक्शन है, जो कार्यान्वयन के लिए 'NotImplementedError' फेंकता है जिसे आप अभी तक लिखने के लिए तैयार नहीं हैं, और मेरा मानना ​​है कि आपके प्रोग्राम में किसी भी संरचनात्मक परिवर्तन करने से अधिक उपयोग करना अधिक सुविधाजनक है। –

+0

क्षमा करें, ओटी = विषय बंद करें। हां ??? मूल्यों को भरने के लिए अच्छा है जबकि "स्केचिंग" हालांकि प्रकार नहीं। –

+0

स्काला से पहले लक्षणों का आविष्कार किया गया था, http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf – iwein