मुझे लगता है कि यहां हितधारकों के दो समूह होने के मुकाबले यह अधिक जटिल है। Project Lambda लोग ज्यादातर ओरेकल लोगों, occasionally throwing something over the wall से स्वतंत्र रूप से काम कर रहे प्रतीत होते हैं कि परियोजना लैम्ब्डा लोग अप्रत्यक्ष रूप से पता लगाते हैं। (स्काला, तीसरे हितधारक निश्चित रूप से है।)
latest Project Lambda proposal के बाद से सभी को एक साथ समारोह प्रकार समाप्त करने के लिए, और सिर्फ इंटरफेस एक भी astract विधि (सैम प्रकार) है कि लागू करने के लिए फैंसी निष्कर्ष के कुछ प्रकार बनाने है, मैं निम्नलिखित पूर्वानुमान:
स्काला कोड है कि एक स्काला बंद की आवश्यकता है Function* लक्षण के कार्यान्वयन (और सामान्य रूप में लक्षण के कार्यान्वयन) पर पूरी तरह से निर्भर करेगा कॉलिंग - चाहे वह एक के रूप में जावा के लिए प्रकट होता सैम (जो स्केल-भूमि में है) या गैर-अमूर्त विधियां भी JVM के लिए सार दिखाई देती हैं। (मुझे लगता है कि वे वर्तमान में अमूर्त हैं क्योंकि लक्षण इंटरफेस के रूप में लागू किए जाते हैं, लेकिन मुझे स्कैला के कार्यान्वयन के बारे में लगभग कुछ भी पता नहीं है। यह इंटरफेरबिलिटी के लिए एक बड़ा बाधा हो सकता है।)
जावा जेनरिक के साथ जटिलताओं (विशेष रूप से Int/int/Integer, या Unit/Nothing/void एक सामान्य इंटरफ़ेस में व्यक्त करने के लिए कैसे चीजों को जटिल कर सकते हैं।
जावा सैम को लागू करने के लिए स्कैला फ़ंक्शंस का उपयोग करना अब इससे अलग नहीं होगा - आपको उस विशिष्ट इंटरफ़ेस के लिए implicit रूपांतरण बनाना होगा, जिसे आप कार्यान्वित करना चाहते हैं।
यदि JVM फ़ंक्शन प्रकार प्राप्त करता है (और ओरेकल उस संभावना को समाप्त नहीं करता है), तो यह निर्भर हो सकता है कि यह कैसे कार्यान्वित किया गया है। यदि वे किसी विशेष इंटरफ़ेस को लागू करने वाली प्रथम श्रेणी की वस्तुएं हैं, तो स्कैला को संगत होने के लिए आवश्यक सभी को Function* नया इंटरफ़ेस लागू करना है।यदि पूरी तरह से JVM में एक नया प्रकार लागू किया गया है, तो यह मुश्किल हो सकता है - स्कैला डेवलपर उन्हें जादू का उपयोग करके लपेट सकते हैं जैसे कि वे वर्तमान में Array एस के लिए करते हैं, या वे implicit रूपांतरण बना सकते हैं। (एक नई भाषा की अवधारणा एक सा दूर से प्राप्त किए गए लगता है।)
मुझे आशा है कि इस चर्चा के सभी के परिणामों में से एक है कि कि विभिन्न JVM भाषाओं कुछ मानक तरीका बंद का प्रतिनिधित्व करने पर सहमत होंगे के सभी - ताकि स्कैला, ग्रोवी, जेआरबी, इत्यादि ... सभी कम से कम परेशानी के साथ आगे और पीछे बंद हो सकते हैं।
मेरे लिए और अधिक दिलचस्प क्या है virtual extension methods के लिए प्रस्ताव है जो जावा कलेक्शन एपीआई को लैम्बडास का उपयोग करने की अनुमति देगा। इन्हें कैसे कार्यान्वित किया जाता है, इस पर निर्भर करते हुए, वे स्केल कोड को बदलने के दौरान निपटने के लिए बाइनरी संगतता समस्याओं में से कुछ को सरल बना सकते हैं, और वे लक्षणों को अधिक आसानी से और कुशलतापूर्वक कार्यान्वित करने में मदद कर सकते हैं।
मुझे उम्मीद है कि कुछ स्कैला डेवलपर्स शामिल हो रहे हैं और अपना इनपुट दे रहे हैं, लेकिन मैंने वास्तव में परियोजना लैम्ब्डा सूचियों पर स्कैला की कोई चर्चा नहीं देखी है, न ही कोई भी प्रतिभागियों जो स्केल डेवलपर्स के रूप में मेरे पास कूदते हैं।
स्रोत
2010-08-04 19:21:39
मुझे संदेह है कि हम जावा 7 रिलीज – CheesePls
के करीब तक एक निश्चित सवाल नहीं जानते हैं। आप निश्चित रूप से स्कैला (और अन्य भाषाओं) से जावा क्लोजर का उपयोग करने में सक्षम होंगे जो रनटाइम ऑपरेटिबिलिटी के लिए अच्छी बात है। लेकिन जावा क्लोजर निर्दिष्ट नहीं हैं इसलिए विवरण अभी तक नहीं हैं। –
@ थॉमस आपको इतना निश्चित बनाता है कि जावा बंद स्केल से उपयोग करने योग्य हैं, इस पर विचार करते हुए कि स्काला बंद करने के लिए कक्षाएं लागू की जाएंगी, इसका मतलब यह नहीं होगा कि जावा को स्केल के FunnctionX को तर्क प्रकार के रूप में उपयोग करना होगा? – soc