Null-Safe Operators (उदाहरण के लिए "एल्विस ऑपरेटर") को Java 7 के "प्रोजेक्ट कॉइन" के भाग के रूप में क्यों अस्वीकार कर दिया गया?


10

जावा 7 के "प्रोजेक्ट कॉइन" के लिए प्रस्तावित सुविधाओं में से एक "एल्विस ऑपरेटर" था। प्रोजेक्ट सिक्के पर 2009 के जावाऑन प्रस्तुति की एक रिपोर्ट ने इसे इस तरह वर्णित किया:

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

जबकि प्रोजेक्ट कॉइन के अन्य पहलुओं को अंततः लागू किया गया था, यह एक नहीं था। शामिल होने के लिए संभावित उम्मीदवार के रूप में जावाऑन में प्रस्तुत किए जाने के बावजूद एल्विस ऑपरेटर को आखिरकार क्यों खारिज कर दिया गया?

स्पष्ट होने के लिए, मैं विशेष रूप से इस ऑपरेटर के बारे में पूछ रहा हूं और इसका कारण यह है कि इसे जावा 7 के "प्रोजेक्ट कॉइन" के हिस्से के रूप में खारिज कर दिया गया था, यह देखते हुए कि इसे तब गंभीरता से माना गया था। मुझे संदेह है कि मेलिंग सूचियां हैं या ऐसे जहां इसे अस्वीकार करने के कारणों पर चर्चा की गई थी, लेकिन मुझे कुछ भी नहीं मिला। यदि जावा के किसी भी संस्करण में इसे क्यों शामिल नहीं किया गया है, इसके बारे में अधिक सामान्य जानकारी है, जो स्वीकार्य है लेकिन पसंद नहीं है।


4
संदिग्ध दिमाग?
इवान

1
मोट की संभावना है क्योंकि यह वैध मान के रूप में नल के उपयोग का समर्थन करता है और प्रोत्साहित करता है, और अधिक मौलिक रूप से OO सिद्धांतों के लिए काउंटर है क्योंकि आप किसी विधि को निष्पादित करने से पहले किसी ऑब्जेक्ट के प्रकार की जांच करते हैं।
जैक्सबी

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

1
@ वामन: मैंने स्वतंत्र रूप से स्वीकार किया कि मेरा उत्तर मेरी पोस्ट की शुरुआत में अटकलें थीं। हालाँकि, मैंने वैसे भी एक उत्तर पोस्ट किया है क्योंकि 1. मैं मछली देने के बजाय मछली को कैसे सिखा रहा हूं, और 2. इस पोस्ट का इस्तेमाल करीबी लोगों के लिए एक लक्ष्य के रूप में किया जा सकता है, अगर हम अपने कार्ड को सही से खेलते हैं। एक सामान्य विश्लेषण प्रदान करने वाले उत्तर के पीछे का विचार मिनट की भाषा के फैसलों के बारे में अंतहीन तर्कों को हतोत्साहित करना और दूसरों को समग्र मुद्दों के बारे में व्यापक दृष्टिकोण देखने में मदद करना है।
रॉबर्ट हार्वे

@RobertHarvey A "भाषा X में Y की सुविधा क्यों नहीं है" कैनोनिकल डूप लक्ष्य सुविधाजनक होगा, लेकिन इसके वर्तमान स्वरूप में प्रश्न इसके लिए उपयुक्त नहीं है। यदि इस सामान्य प्रश्न ( उदाहरण के?. रूप में X = Java / Y = का उपयोग करके ) इसे संपादित किया जाना था, तो यह निश्चित रूप से एक सामान्य प्रश्न के रूप में व्यापक होगा, लेकिन आपके पास एक अच्छा जवाब होगा।
आमोन

जवाबों:


15

स्वाभाविक रूप से, यह सवाल पूछने वाला सबसे अच्छा व्यक्ति कोई और नहीं , बल्कि JCP कार्यकारी समिति है। हालाँकि, यह मुझे कुछ बेकार की अटकलों में उलझने से नहीं रोकेगा।

हर "इस सुविधा को लागू क्यों नहीं किया गया" का जवाब सवाल हमेशा है क्योंकि लाभ लागत से अधिक नहीं थे।

एरिक लिपर्ट (C # टीम के पूर्व सदस्य) का कहना है कि, किसी उत्पाद के लिए एक विशेषता के लिए, यह सुविधा होनी चाहिए:

  • पहली जगह में सोचा
  • चाहा हे
  • डिज़ाइन किया गया
  • निर्दिष्ट
  • कार्यान्वित
  • परीक्षण किया
  • दस्तावेज
  • ग्राहकों के लिए भेज दिया

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

C # टीम पर, प्रत्येक नई सुविधा अनुरोध माइनस 100 के स्कोर के साथ शुरू होता है। तब टीम लाभों और लागतों का मूल्यांकन करती है, लाभों के लिए अंक जोड़ती है, और लागतों के लिए अंकों को घटाती है। यदि स्कोर शून्य से ऊपर नहीं जाता है, तो प्रस्तावित सुविधा संक्षेप में खारिज कर दी जाती है। दूसरे शब्दों में, नई सुविधा को एक सम्मोहक लाभ प्रदान करना चाहिए।

लेकिन एल्विस ऑपरेटर ने इसे C # में बनाया। तो यह जावा में क्यों नहीं बनाया?

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

इस रेडिट एक्सचेंज पर विचार करें :

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

यदि आपके पास 15+ वर्ष के जावा की टीम है जो किसी प्रकार के अत्यधिक वितरित, उच्च-समवर्ती बैकेंड प्रसंस्करण प्रणाली को लिखने के लिए मुकदमा करता है, तो आप शायद वास्तुशिल्प कठोरता का एक बड़ा हिस्सा चाहते हैं।

हालाँकि, यदि आपके पास मध्य-स्तर की टीम में जूनियर हैं, जिनमें से आधे विजुअल बेसिक से चले गए हैं, और आपने उन्हें एक ASP.NET वेब ऐप लिखी है, जो ज्यादातर CRUD ऑपरेशन ही करता है ... तो हो सकता है कि यह एक गुच्छा डिजाइन करने के लिए ओवरकिल हो। का AbstractFactoryFactoryसार दूर सच है कि आप कोई नियंत्रण नहीं है जिस पर कॉलम shitty विरासत डेटाबेस है कि आप का उपयोग करना चाहिए में नल हैं कि करने के लिए कक्षाएं।

भाषा दर्शन में ये गहरा अंतर न केवल भाषाओं के उपयोग करने के तरीके पर निर्भर करता है, बल्कि जिस तरह से भाषा की डिजाइन प्रक्रिया स्वयं की जाती है। C # एक उदार तानाशाह भाषा है। C # में एक नई सुविधा प्राप्त करने के लिए, आपको वास्तव में केवल एक व्यक्ति को समझाना होगा: Anders Hejlsberg

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

सवाल "क्यों एक्स फ़ीचर लागू नहीं किया गया था ..." हमेशा स्पष्ट रूप से शब्द शामिल हैं, "... अगर यह स्पष्ट रूप से इतना अच्छा विचार है?" जैसा कि मैंने यहां पर्याप्त रूप से प्रदर्शित किया है, पसंद कभी भी सरल नहीं होती है।


8
कटाक्ष: क्योंकि AbstractFactoryFactory कक्षाएं वास्तु कठोरता का एक अच्छा संकेतक हैं, और कोड ब्लोटिंग नहीं। / व्यंग्य।
मचाडो

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

5
आपके द्वारा सूचीबद्ध पहले के अधिकांश कारण - हर भाषा की विशेषता किसी के भी विचार, परिमित बजट (प्रयास के लिए, परिवर्तन के लिए, जटिलता के लिए) से बड़ी है - सटीक हैं। और मैं जोड़ूंगा: हम सुविधा X नहीं करते क्योंकि हमें लगता है कि अन्य सुविधाएँ Y और Z बेहतर विकल्प हैं। इसके अलावा, हम अन्य भाषाओं की तुलना में अधिक रूढ़िवादी दृष्टिकोण भी अपनाते हैं, क्योंकि हम जानते हैं कि प्रत्येक विशेषता भविष्य में अन्य संभावित विशेषताओं के साथ, या कुछ मामलों में फोरक्लोज करती है। हम चाहते हैं कि जावा 20 वर्षों में जीवंत और प्रासंगिक बना रहे, जिसका अर्थ यह है कि हर सुविधा जो अब ठंडी लग सकती है, में cramming नहीं है।
ब्रायन गोएट्ज़

1
@BrianGoetz: चूंकि यह समस्या "कमेटी द्वारा डिज़ाइन" शब्द की सहायक प्रकृति की प्रतीत होती है (आप ध्यान देंगे कि मैंने जावा को किसी अन्य तरीके से नापसंद नहीं किया है), मैंने शब्द को हटाने के लिए अपना उत्तर थोड़ा बदल दिया है।
रॉबर्ट हार्वे

1
सी # और जावा डिजाइनरों के बीच कुछ प्रतिद्वंद्विता हुआ करती थी। जावा डिजाइनरों द्वारा C # को चीर-फाड़ माना जाता था (और ठीक ही ऐसा)। C # प्रतिनिधियों को "ऑब्जेक्ट ओरिएंटेड नहीं" होने के कारण खारिज कर दिया गया था, लेकिन असली कारण यह था कि वे C # पहले दिखाई दिए थे। यह सोचना अच्छा है कि यह केवल तर्कसंगत कारणों से है कि कुछ विशेषताएं जोड़ी जाती हैं या छोड़ दी जाती हैं ... मुझे इसमें संदेह है।
फ्रैंक हिलमैन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.