स्कैला में "<:" का क्या अर्थ है?

Question

मैं पी देख रहा हूँ। 46 9 "प्रोग्रामिंग इन स्कैला" द्वितीय संस्करण। कोड की एक पंक्ति है जो पढ़ती है:

type Currency <: AbstractCurrency 

मैं इसका अर्थ समझ नहीं सकता।

Answer 1

इसका मतलब है कि एक अमूर्त प्रकार का सदस्य परिभाषित किया गया है (कुछ संदर्भों के अंदर, उदाहरण के लिए एक विशेषता या कक्षा), ताकि उस संदर्भ के ठोस कार्यान्वयन को उस प्रकार को परिभाषित किया जाना चाहिए। हालांकि, एक बाधा है कि इस प्रकार (Currency) वास्तव में उपप्रकारAbstractCurrency होना चाहिए। इस तरह अमूर्त संदर्भ Currency के साथ काम कर सकता है, यह जानकर कि यह AbstractCurrency के प्रत्येक ऑपरेशन को समझता है।

trait AbstractCurrency { 
    def disappearInGreece(): Unit 
} 

abstract class Economy { 
    type Currency <: AbstractCurrency 

    def curr: Currency 

    // can call disappear... because `Currency` 
    // is an `AbstractCurrency` 
    def shake(): Unit = curr.disappearInGreece() 
} 

बाधाओं के बिना Currency परिभाषित करने के लिए कोशिश कर रहा है:

trait RadioactiveBeef 

class NiceTry(val curr: RadioactiveBeef) extends Economy { 
    type Currency = RadioactiveBeef 
} 

विफल।ठीक की कमी के साथ:

trait Euro extends AbstractCurrency 

class Angela(val curr: Euro) extends Economy { 
    type Currency = Euro 
} 

Answer 2

इसका मतलब है "का एक उप प्रकार होना चाहिए", "अनुरूप होना चाहिए", "विस्तारित होना चाहिए"। अधिकांश समय, यह एक सामान्य पैरामीटर पर एक बाध्य रूप में प्रकट होता है, जैसे

class Home[P <: Person] 

प्रत्येक घर व्यक्ति की एक निश्चित प्रकार के लिए फिट है के रूप में एक Home[Person] किसी भी व्यक्ति को स्वीकार करता है, हो सकता है Home[Student], Home[Elderly], लेकिन Home[Planet] नहीं।

type Currency <: AbstractCurrencyclass/trait जहां यह प्रतीत होता है में एक सार type सदस्य Currency परिचय देता है। वंशजों को एक प्रकार का चयन करना होगा ताकि वे ठोस हो सकें। <: सार मुद्राएं उन्हें AbstractCurrency (AbstractCurrency सहित) के उप प्रकार का चयन करने के लिए मजबूर करती हैं, जिन्हें अनुमति है)।

एक सार प्रकार का सदस्य एक प्रकार पैरामीटर के बहुत करीब है, जैसे एक सार मूल्य सदस्य एक निर्माता पैरामीटर के करीब है।

यदि आपके पास class A(val x: X){...} है, तो आप new A(myX) के साथ पहले को इंस्टेंट करें। यदि आपके पास class A{val x: X; ...} है, तो आप नए A{val x = myX } के साथ instanciate।

यदि आपके पास class Market[Currency <: AbstractCurrency] है तो आप Market[SomeCurrencyType] के साथ प्रकार को instanciate। यदि आपके पास Market{type Currency <: AbstractCurrency} है, तो आप Market{type Currency = SomeCurrencyType} के साथ तत्काल हैं। हालांकि, Market एक वैध प्रकार है। इसका मतलब है कि आप नहीं जानते कि इस बाजार का किस प्रकार की मुद्रा उपयोग करती है (जो आप इसे कैसे उपयोग कर सकते हैं प्रतिबंधित कर सकते हैं)।

एक सार प्रकार सदस्य के बजाय एक प्रकार पैरामीटर का उपयोग करते हुए लाभ हो सकता है, ज्यादातर अगर प्रकार पैरामीटर, नहीं प्रकार के सार्वजनिक इंटरफ़ेस में प्रकट नहीं होता है, तो Market कोई Currency एक समारोह पैरामीटर या परिणाम के रूप में दिखाई दे रहा है (इस उदाहरण पर भी संभावना है)। फिर ग्राहक को Market[SomeCurrencyType], Market लिखने की आवश्यकता नहीं है। बेशक, CurrencyType को बाजार के निर्माण के समय जाना होगा, लेकिन फिर इसे Market के साथ पास किया जा सकता है।

Answer 3

यह सवाल स्काला के बारे में है, लेकिन मुझे लगता है कि यह उल्लेख है कि <: [? प्रकार operatator] स्काला लिए अद्वितीय नहीं है और इसके बजाय प्रकार थ्योरी में निकलती है लायक है; उदाहरण के लिए विकिपीडिया पर Subtyping के बारे में आलेख देखें जो इस ऑपरेटर का व्यापक उपयोग करता है।

वास्तव में, प्रकार सिद्धांत <: के साथ अपने मजबूत कनेक्शन के कारण स्कैला (सुंदरता से) उधार लिया गया एकमात्र चीज नहीं है; उदाहरण के लिए term: Type नोटेशन (उदाहरण में val foo: Foo, def fact(x: Int): Int में देखा गया) Type Theory से भी आता है।

Answer 4

मैं कुछ बिंदु जोड़ना चाहता हूं जो <: उपयोगिता के उपयोगिता लाभों का वर्णन करेंगे।

आप अपने एपीआई के लिए निम्नलिखित वर्ग को परिभाषित हमें मान लीजिए,:

case object Parameter1 extends BaseParameter 
case object Parameter2 extends BaseParameter 
case object Parameter3 

:

case class myApiClass[param <: BaseParameter](requestBody: String, parameter: param) 

आप एक विशेषता BaseParameter

trait BaseParameter 

फिर, आप निम्न पैरामीटर कहा जाता है

अब, जब भी आप myApiClass उदाहरण बनाते हैं, तो आपको किसी ऑब्जेक्ट को तर्क "पैरामीटर" के रूप में पास करना होगा, जिसका वर्ग/जो स्वयं बेस पैरामीटर लागू करता है (उदा। पैरामीटर 1 और पैरामीटर 2)। कंक्रीटली, यह एक दावा है, और अगर आप पैरामीटर 3 पास करते हैं तो काम नहीं करेंगे।