2017-06-14 6 views
6

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

मुझे पता है कि if-else और when कथन में कोड के ब्लॉक हैं, तो अंतिम अभिव्यक्ति वापस आती है। अगले उदाहरण में 1 या 2 स्थिति के आधार पर लौटा दिए गए हैं - हमारे मामले में यह 1 देता है।

val x = if (1 < 2) {println("something"); 1} else {println("something else"); 2} 

दूसरी ओर यह किसी भी कोड ब्लॉक के लिए नहीं है। अगली पंक्ति y1 पर नहीं बल्कि लैम्बडा के रूप में कोड के पूरे ब्लॉक को असाइन करती है।

val y = {println("something"); 1} 

इसी तरह फ़ंक्शन बॉडी में, अंतिम अभिव्यक्ति वापस नहीं आती है। यह संकलन भी नहीं करता है।

fun z() : Int { 
    println("something") 
    1 
} 

तो नियम वास्तव में क्या है? क्या यह वास्तव में इतनी मनमानी है: यदि if-else या when कथन में अभिव्यक्ति के रूप में उपयोग किया गया है तो कोड का एक ब्लॉक है, तो ब्लॉक में अंतिम अभिव्यक्ति वापस आती है। अन्यथा अंतिम अभिव्यक्ति बाहरी दायरे में वापस नहीं आती है। या क्या मैं कुछ न कुछ भूल रहा हूं?

उत्तर

4

आप, कर्ली कोष्ठक {} गलत जब चारों तरफ flow-control बयान के साथ यह सिर्फ एक ब्लॉक है, उदाहरण के लिए:

if (condition) { //block here 
} 

जब{} अलग से घोषित किया जाता है यह एक लैम्ब्डा अभिव्यक्ति है , उदाहरण के लिए:

val lambda:() -> Int = { 1 }; // lambda 

जब आप एक lambdaif-else में अभिव्यक्ति वापस जाने के लिए चाहते हैं, आप कर्ली कोष्ठक {} या का उपयोग कर कोष्ठक ()ब्लॉक और लैम्ब्डा अभिव्यक्ति के बीच अंतर करना दोगुना या उदाहरण के लिए स्पष्ट रूप से लैम्ब्डा के रूप में {} बनाने के लिए, करना होगा:

val lambda1:() -> Int = if (condition) { { 1 } } else { { 2 } }; 
val lambda2:() -> Int = if (condition) ({ 1 }) else ({ 2 }); 
val lambda3:() -> Int = if (condition) { -> 1 } else { -> 2 }; 

एक समारोह किसी भी उपयोगी मूल्य वापस नहीं करता है, तो उसके वापसी प्रकार Unit है। Unit एक प्रकार का एक प्रकार है - Unit। इस मान को स्पष्ट रूप से वापस नहीं किया जाना है।

दूसरी ओर, एक आमfunction नहीं तो अगर इसकी वापसी प्रकार एक Unit एक स्पष्ट return बयान होना चाहिए:

fun z(): Int { return 1; } 

एक और मामला एक समारोह वापसी Nothing है, return बयान डॉन बिल्कुल अनुमति नहीं है, क्योंकि आप Nothing उदाहरण नहीं बना सकते हैं, उदाहरण के लिए:

fun nothing(): Nothing { 
    return ?;// a compile error raising 
} 

एक समारोह केवल एक अभिव्यक्ति तो है, जब आप single-expression function बजाय का उपयोग कर सकते हैं, उदाहरण के लिए:

fun z() = 1; 
+1

हाँ, यह शायद है मैं क्या मतलब मेरी टिप्पणी से। '{}' में तीन (या इससे भी ज्यादा? क्या मुझे कुछ याद आ रही है?) अलग-अलग भूमिकाएं - यह नियंत्रण प्रवाह विवरण में एक ब्लॉक हो सकती है या यह लैम्ब्डा हो सकती है या यह एक फ़ंक्शन बॉडी हो सकती है। और इन सभी मामलों पर विभिन्न नियम लागू होते हैं। मेरा मतलब यह नहीं है कि मैं चिल्लाता हूं या शिकायत करता हूं, मुझे इसे लेना होगा। लेकिन यह मुझे अन्यथा सही भाषा के असंगत भाषा डिजाइन दोष की एक छोटी सी प्रतीत होता है। –

+0

@ वी.के. जी श्रीमान। तुम सही हो। –

+1

इस कोड से मेरी कोडिंग शैली दूर-दूर है कि मैं अभिव्यक्ति के रूप में उपयोग किए जाने पर नियंत्रण प्रवाह विवरणों में ब्लॉक से बचने की कोशिश करूंगा। मैं सी ++ और पायथन क्षेत्र से आ रहा हूं और 'ब्लॉक में आखिरी अभिव्यक्ति को वापस करने' जैसी कोई बात नहीं है, इसलिए मैं केवल 'अभिव्यक्ति के रूप में' if' या 'जब' अभिव्यक्ति के रूप में उपयोग करता हूं, जब लौटा हुआ अभिव्यक्ति छोटा होता है (ब्लॉक के बिना), उदा। 'ए = अगर (एक्स) वाई अन्य z'। अन्यथा मैं पूर्ण उड़ा वाक्यविन्यास 'अगर (x) {println ("कुछ") का उपयोग करूंगा; ए = वाई} अन्य {println ("कुछ और"); ए = जेड} 'जैसा कि हम अन्य भाषाओं से जानते हैं। –

2

वहाँ अपने मामले "y, एक लैम्ब्डा ब्लॉक और सिर्फ एक 'सामान्य' ब्लॉक के बीच एक अंतर है "सिर्फ एक लैम्ब्डा दिए गए मान प्राप्त करने के लिए निष्पादित करने की आवश्यकता है जो:

val block:() -> Int = { 5 } 
val five: Int = { 5 }() 
val anotherFive = block() 

तो अगर आप एक ब्लॉक है कि एक लैम्ब्डा के रूप में कार्य करना चाहते हैं, आप एक लैम्ब्डा बना सकते हैं और यह सही के साथ भाग पर अमल"() " । इस तरह, आपके "Z" समारोह इतना तरह संकलन होगा:

fun z() : Int = { println("something") 1 }()

(कौन सा, ज़ाहिर है, ज्यादा मतलब नहीं है और बहुत ही कुशल नहीं है)

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