क्या आप "स्पष्ट" संग्रह विधियों के लिए स्कैलाडोक पढ़ते हैं? या आलस हमेशा अच्छा क्यों नहीं होता

यदि आप नहीं जानते कि वे कैसे भिन्न हैं

someMap.map{ case (k, v) => k -> foo(v)} 

और

 someMap.mapValues(foo) 

सिंटैक्स को छोड़कर, या आपको संदेह है / पता नहीं है कि इस अंतर के क्या बुरे परिणाम हो सकते हैं, और कहां identity होती identity , तो यह लेख आपके लिए है।

अन्यथा, लेख के अंत में स्थित सर्वेक्षण में भाग लें।

एक सरल से शुरू करते हैं

आइए कोशिश करते हैं कि कट से पहले स्थित एक उदाहरण लें और देखें कि क्या होता है:

 val someMap = Map("key1" -> "value1", "key2" -> "value2") def foo(value: String): String = value + "_changed" val resultMap = someMap.map{case (k,v) => k -> foo(v)} val resultMapValues = someMap.mapValues(foo) println(s"resultMap: $resultMap") println(s"resultMapValues: $resultMapValues") println(s"equality: ${resultMap == resultMapValues}") 

इस कोड के प्रिंट होने की उम्मीद है

 resultMap: Map(key1 -> value1_changed, key2 -> value2_changed) resultMapValues: Map(key1 -> value1_changed, key2 -> value2_changed) equality: true 

और इस स्तर के बारे में, mapValues विधि की समझ स्काला को सीखने के शुरुआती चरणों में mapValues है: ठीक है, हाँ, ऐसी एक विधि है, जब चाबियाँ नहीं बदलती हैं तो Map में मान बदलना सुविधाजनक होता है। और वास्तव में, सोचने के लिए और क्या है? विधि के नाम से, सब कुछ स्पष्ट है, व्यवहार स्पष्ट है।

अधिक जटिल उदाहरण

आइए हमारे उदाहरण को थोड़ा संशोधित करें (मैं स्पष्ट रूप से ऐसे प्रकार लिखूंगा ताकि आप यह न सोचें कि कुछ प्रकार की बातों के साथ छेड़छाड़ होती है):

 case class ValueHolder(value: String) val someMap: Map[String, String] = Map("key1" -> "value1", "key2" -> "value2") def foo(value: String): ValueHolder = ValueHolder(value) val resultMap: Map[String, ValueHolder] = someMap.map{case (k,v) => k -> foo(v)} val resultMapValues: Map[String, ValueHolder] = someMap.mapValues(foo) println(s"resultMap: $resultMap") println(s"resultMapValues: $resultMapValues") println(s"equality: ${resultMap == resultMapValues}") 

और लॉन्च के बाद इस तरह के कोड का उत्पादन होगा

 resultMap: Map(key1 -> ValueHolder(value1), key2 -> ValueHolder(value2)) resultMapValues: Map(key1 -> ValueHolder(value1), key2 -> ValueHolder(value2)) equality: true 

यह काफी तार्किक और स्पष्ट है। "यार, यह लेख के तल पर जाने का समय है!" - पाठक कहेंगे। आइए, अपनी कक्षा के निर्माण को बाहरी परिस्थितियों पर निर्भर करें और मुहावरों के लिए कुछ सरल जाँचें जोड़ें:

 case class ValueHolder(value: String, seed: Int) def foo(value: String): ValueHolder = ValueHolder(value, Random.nextInt()) ... println(s"simple assert for resultMap: ${resultMap.head == resultMap.head}") println(s"simple assert for resultMapValues: ${resultMapValues.head == resultMapValues.head}") 

उत्पादन में हम प्राप्त:

 resultMap: Map(key1 -> ValueHolder(value1,1189482436), key2 -> ValueHolder(value2,-702760039)) resultMapValues: Map(key1 -> ValueHolder(value1,-1354493526), key2 -> ValueHolder(value2,-379389312)) equality: false simple assert for resultMap: true simple assert for resultMapValues: false 

यह तर्कसंगत है कि परिणाम अब समान नहीं हैं, लेकिन यादृच्छिक हैं। लेकिन रुकिए, दूसरे दावे को false क्यों बताया? वास्तव में resultMapValues के मूल्य बदल गए हैं, हमने उनके साथ कुछ भी नहीं किया है? आइए देखें कि क्या अंदर सब कुछ वैसा ही है जैसा कि था:

 println(s"resultMapValues: $resultMapValues") println(s"resultMapValues: $resultMapValues") 

और हमें प्राप्त होने वाले उत्पादन में:

 resultMapValues: Map(key1 -> ValueHolder(value1,1771067356), key2 -> ValueHolder(value2,2034115276)) resultMapValues: Map(key1 -> ValueHolder(value1,-625731649), key2 -> ValueHolder(value2,-1815306407)) 

ऐसा क्यों हुआ?

println Map का मान क्यों बदलता है?
mapValues विधि के लिए दस्तावेज़ में आने का समय है:

  /** Transforms this map by applying a function to every retrieved value. * @param f the function used to transform values of this map. * @return a map view which maps every key of this map * to `f(this(key))`. The resulting map wraps the original map without copying any elements. */ 

पहली पंक्ति हमें बताती है कि हमने क्या सोचा था - यह Map बदलता है, प्रत्येक मान के तर्कों में पारित फ़ंक्शन को लागू करता है। लेकिन अगर आप इसे बहुत ध्यान से और अंत तक पढ़ते हैं, तो यह पता चलता है कि यह Map नहीं है जो वापस आ गया है, लेकिन "मैप व्यू" (देखें)। और यह एक सामान्य दृश्य ( View ) नहीं है, जिसे आप view पद्धति का उपयोग करके प्राप्त कर सकते हैं और जिसमें स्पष्ट गणना के लिए एक force विधि है। एक विशेष वर्ग (कोड स्कैला संस्करण 2.12.7 से है, लेकिन 2.11 के लिए लगभग एक ही बात है):

 protected class MappedValues[W](f: V => W) extends AbstractMap[K, W] with DefaultMap[K, W] { override def foreach[U](g: ((K, W)) => U): Unit = for ((k, v) <- self) g((k, f(v))) def iterator = for ((k, v) <- self.iterator) yield (k, f(v)) override def size = self.size override def contains(key: K) = self.contains(key) def get(key: K) = self.get(key).map(f) } 

यदि आप इस कोड को पढ़ते हैं, तो आप देखेंगे कि कुछ भी कैश नहीं है, और हर बार जब आप मूल्यों को एक्सेस करते हैं, तो उन्हें फिर से गणना की जाएगी। हम अपने उदाहरण में क्या देखते हैं।

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

बेशक, हम इस पार आने वाले पहले व्यक्ति नहीं हैं। पहले से ही 2011 में, इस अवसर पर एक बड़ा बग खोला गया था (और लेखन के समय, इसे खुले रूप में चिह्नित किया गया है)। इसमें filterKeys विधि का भी उल्लेख किया filterKeys है, जिसमें बिल्कुल वही समस्याएं हैं, क्योंकि यह एक ही सिद्धांत पर लागू किया जाता है।

इसके अलावा, 2015 के बाद से, IntelliJ Idea में निरीक्षण जोड़ने के लिए एक टिकट लटका हुआ है।

क्या करें?

सबसे सरल उपाय यह है कि इन विधियों का उपयोग न करें नाम से, उनका व्यवहार, मेरी राय में, बहुत ही स्पष्ट है।

थोड़ा बेहतर विकल्प map(identity) को कॉल करना है।
identity , अगर किसी को पता नहीं है, यह मानक पुस्तकालय से एक फ़ंक्शन है जो केवल अपने इनपुट तर्क को लौटाता है। इस मामले में, मुख्य विधि map विधि है, जो स्पष्ट रूप से एक सामान्य Map । चलो बस मामले में जाँच करें:

 val resultMapValues: Map[String, ValueHolder] = someMap.mapValues(foo).map(identity) println(s"resultMapValues: $resultMapValues") println(s"simple assert for resultMapValues: ${resultMapValues.head == resultMapValues.head}") println(s"resultMapValues: $resultMapValues") println(s"resultMapValues: $resultMapValues") 

हमें जो आउटपुट मिलता है

 resultMapValues: Map(key1 -> ValueHolder(value1,333546604), key2 -> ValueHolder(value2,228749608)) simple assert for resultMapValues: true resultMapValues: Map(key1 -> ValueHolder(value1,333546604), key2 -> ValueHolder(value2,228749608)) resultMapValues: Map(key1 -> ValueHolder(value1,333546604), key2 -> ValueHolder(value2,228749608)) 

सब ठीक है :)

यदि आप अभी भी आलस छोड़ना चाहते हैं, तो कोड को बदलना बेहतर है ताकि यह स्पष्ट हो। आप mapValues और filterKeys लिए एक आवरण विधि के साथ एक अंतर्निहित वर्ग बना सकते हैं, जो एक नया नाम देता है जो उनके लिए समझ में आता है। या स्पष्ट रूप से .view उपयोग करें और जोड़े के .view साथ काम करें।

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

आप रेक पर और कैसे कदम बढ़ा सकते हैं और हमने उन पर कैसे कदम रखा

बाहरी स्थितियों पर निर्भरता के साथ मामले के अलावा, जो हमने ऊपर के उदाहरणों में देखा था, अन्य विकल्प हैं।

उदाहरण के लिए, एक परिवर्तनशील मूल्य (नोट, यहाँ सतही नज़र में सब कुछ "अपरिवर्तनीय" है):

 val someMap1 = Map("key1" -> new AtomicInteger(0), "key2" -> new AtomicInteger(0)) val someMap2 = Map("key1" -> new AtomicInteger(0), "key2" -> new AtomicInteger(0)) def increment(value: AtomicInteger): Int = value.incrementAndGet() val resultMap: Map[String, Int] = someMap1.map { case (k, v) => k -> increment(v) } val resultMapValues: Map[String, Int] = someMap2.mapValues(increment) println(s"resultMap (1): $resultMap") println(s"resultMapValues (1): $resultMapValues") println(s"resultMap (2): $resultMap") println(s"resultMapValues (2): $resultMapValues") 

यह कोड इस परिणाम का उत्पादन करेगा:

 resultMap (1): Map(key1 -> 1, key2 -> 1) resultMapValues (1): Map(key1 -> 1, key2 -> 1) resultMap (2): Map(key1 -> 1, key2 -> 1) resultMapValues (2): Map(key1 -> 2, key2 -> 2) 

जब मैंने कुछ someMap2 फिर से एक्सेस किया, someMap2 एक मजेदार परिणाम मिला।

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

आपको toSeq की toSeq विधि को समान रेक के गुल्लक में भी जोड़ना चाहिए, जो एक आलसी Stream देता है।

हम दुर्घटना से mapValues पर रेक करते हैं। यह एक विधि में इस्तेमाल किया गया था, जो कि प्रतिबिंब का उपयोग करके, विन्यास से हैंडलर का एक सेट बनाया गया था: कुंजी हैंडलर के पहचानकर्ता थे, और मूल्य उनकी सेटिंग्स थे, जो तब स्वयं हैंडलर में परिवर्तित हो गए थे (वर्ग उदाहरण बनाया गया था)। चूंकि हैंडलर में केवल शुद्ध कार्य शामिल थे, इसलिए सब कुछ समस्याओं के बिना काम किया, यहां तक ​​कि ध्यान देने योग्य भी प्रदर्शन को प्रभावित नहीं किया (रेक लेने के बाद, हमने माप लिया)।

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

यदि आप अपाचे स्पार्क के साथ काम कर रहे हैं, तो आप एक समान समस्या पर ठोकर खा सकते हैं जब आप अचानक पाते हैं कि .mapValues के साथ कोड के कुछ प्राथमिक के लिए आप पकड़ सकते हैं।

 java.io.NotSerializableException: scala.collection.immutable.MapLike$$anon$2 

https://stackoverflow.com/questions/32900862/map-can-not-be-serializable-in-scala
https://issues.scala-lang.org/browse/SI-7005
लेकिन map(identity) समस्या को हल करता है, और आमतौर पर गहरी खुदाई करने के लिए कोई प्रेरणा / समय नहीं होता है।

निष्कर्ष

त्रुटियां सबसे अप्रत्याशित स्थानों में दुबक सकती हैं - यहां तक ​​कि उन तरीकों में भी जो 100% स्पष्ट लगते हैं। विशेष रूप से, यह समस्या, मेरी राय में, एक खराब पद्धति के नाम और एक अपर्याप्त सख्त वापसी प्रकार से जुड़ी है।

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

अकेले आलसी कंप्यूटिंग एक अच्छा मजाक है, और लेख किसी भी तरह से उन्हें छोड़ने के लिए प्रोत्साहित नहीं करता है। हालांकि, जब आलस्य स्पष्ट नहीं होता है - इससे समस्याएं हो सकती हैं।

निष्पक्षता में, mapValues साथ समस्या पहले से ही अनुवाद में mapValues पर दिखाई देती थी , लेकिन व्यक्तिगत रूप से, उस लेख को मैंने अपने सिर में बहुत बुरी तरह से डाल दिया था, क्योंकि कई पहले से ही ज्ञात / बुनियादी चीजें थीं और यह पूरी तरह से स्पष्ट नहीं था कि इन कार्यों का उपयोग करने का खतरा क्या हो सकता है:

FilterKeys विधि किसी भी तत्व को कॉपी किए बिना स्रोत तालिका को लपेटती है। वहाँ कुछ भी गलत नहीं है, लेकिन आप शायद ही फ़िल्टरकी से इस व्यवहार की उम्मीद करते हैं

यही है, अप्रत्याशित व्यवहार के बारे में एक टिप्पणी है, और एक ही समय में आप रेक पर भी थोड़ा कदम बढ़ा सकते हैं, जाहिर है, इसे संभावना नहीं माना जाता है।

→ लेख का सारा कोड इस सार में है