हम इंटेलीज आईडीईए में लैंबडा एक्सप्रेशन कैसे देखते हैं

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

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

यदि हम एक कार्यात्मक इंटरफ़ेस के साथ काम नहीं कर रहे हैं, तो तत्काल वारिस ढूंढना एक सरल कार्य है। Foo इंटरफ़ेस के कार्यान्वयन के लिए खोज करते समय, आपको उन सभी वर्गों को खोजने की आवश्यकता होती है, जहां implements Foo , और इंटरफेस जहां extends Foo को extends Foo जाता है, साथ ही new Foo(...) {...} फॉर्म के अनाम कक्षाएं new Foo(...) {...} । ऐसा करने के लिए, अग्रिम में प्रत्येक परियोजना फ़ाइल के वाक्यविन्यास वृक्ष का निर्माण करने के लिए पर्याप्त है, संबंधित निर्माणों को ढूंढें और उन्हें सूचकांक में जोड़ें।

बेशक, यहां थोड़ी सूक्ष्मता है: शायद आप com.example.goodcompany.Foo इंटरफ़ेस की तलाश कर रहे हैं, लेकिन कहीं न कहीं org.example.evilcompany.Foo वास्तव में उपयोग किया जाता है। क्या इंडेक्स में पैरेंट इंटरफेस का पूरा नाम प्री-डालना संभव है? इससे मुश्किलें हैं। उदाहरण के लिए, इंटरफ़ेस का उपयोग करने वाली फ़ाइल इस तरह दिख सकती है:

 // MyFoo.java import org.example.foo.*; import org.example.bar.*; import org.example.evilcompany.*; class MyFoo implements Foo {...} 

केवल फ़ाइल को देखते हुए, हम यह नहीं समझ सकते हैं कि वास्तविक पूर्ण नाम Foo । आपको कई पैकेजों की सामग्री को देखना होगा। और प्रत्येक पैकेज को कई जगहों पर परिभाषित किया जा सकता है (उदाहरण के लिए, कई जार फ़ाइलों में)। अनुक्रमण में एक लंबा समय लगेगा यदि, इस फ़ाइल का विश्लेषण करने में, हमें चरित्र का पूर्ण संकल्प करना होगा। लेकिन मुख्य समस्या यह भी नहीं है, लेकिन यह है कि MyFoo.java फ़ाइल पर बनाया गया सूचकांक न केवल उस पर निर्भर करेगा, बल्कि अन्य फाइलों पर भी निर्भर करेगा। आखिरकार, हम Foo इंटरफ़ेस के विवरण को स्थानांतरित कर सकते हैं, उदाहरण के लिए, org.example.foo पैकेज से org.example.bar पैकेज से, और MyFoo.java फ़ाइल में कुछ भी न बदलें, और Foo का पूरा नाम बदल जाएगा।

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

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

मान लीजिए कि हमारे पास एक कार्यात्मक इंटरफ़ेस है:

 @FunctionalInterface public interface StringConsumer { void consume(String s); } 

कोड में अलग-अलग लैम्ब्डा एक्सप्रेशन हैं। उदाहरण के लिए:

 () -> {} //   :   (a, b) -> a + b //   :   s -> { return list.add(s); //   :   } s -> list.add(s); //    

यही है, हम केवल उन लैम्ब्डों को जल्दी से फ़िल्टर कर सकते हैं जिनमें गलत संख्या में पैरामीटर हैं या स्पष्ट रूप से गलत रिटर्न प्रकार है, उदाहरण के लिए शून्य बनाम गैर-शून्य। आमतौर पर रिटर्न प्रकार को अधिक सटीक रूप से निर्धारित करना असंभव है। कहते हैं, lambda s -> list.add(s) लिए आपको वर्ण list को हल करने और add , और संभवतया, एक पूर्ण प्रकार की इंजेक्शन प्रक्रिया शुरू करें। यह सब लंबा है और अन्य फ़ाइलों की सामग्री पर बन्धन की आवश्यकता होगी।

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

शायद आपको कुछ समझने के लिए मेमने के चारों ओर देखना चाहिए? हां, कभी-कभी यह काम करता है। उदाहरण के लिए:

 //        Predicate<String> p = s -> list.add(s); //      IntPredicate getPredicate() { return s -> list.add(s); } //      SomeType fn; fn = s -> list.add(s); //     foo((SomeFunctionalType)(s -> list.add(s))); //     Foo[] myLambdas = {s -> list.add(s), s -> list.remove(s)}; 

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

 list.stream() .filter(s -> StringUtil.isNonEmpty(s)) .map(s -> s.trim()) .forEach(s -> list.add(s)); 

इन तीन लैंबडों में से कौन सा स्ट्रिंगरकोनसमर हो सकता है? यह प्रोग्रामर को स्पष्ट है कि कोई नहीं। क्योंकि यह स्पष्ट है कि यहां हमारे पास स्ट्रीम एपीआई श्रृंखला है, और मानक पुस्तकालय से केवल कार्यात्मक इंटरफेस हैं, हमारा प्रकार वहां नहीं हो सकता है।

हालांकि, आईडीई को खुद को धोखा नहीं देना चाहिए, उसे सटीक जवाब देना चाहिए। क्या होगा अगर list java.util.List नहीं है। सभी पर जाएं, और list.stream() java.util.stream.Stream वापस नहीं आती है। ऐसा करने के लिए, आपको list प्रतीक को हल करना होगा, जो कि हम जानते हैं, केवल वर्तमान फ़ाइल की सामग्री के आधार पर मज़बूती से नहीं किया जा सकता है। और यहां तक ​​कि अगर हमने इसे स्थापित किया है, तो खोज को मानक पुस्तकालय के कार्यान्वयन पर नहीं रखा जाना चाहिए। हो सकता है कि हम इस परियोजना में विशेष रूप से java.util.List जगह ले लें। अपने वर्ग के साथ? खोज को इसका जवाब देना होगा। खैर, निश्चित रूप से, लैम्ब्डा का उपयोग न केवल मानक धाराओं में किया जाता है, कई अन्य तरीके भी हैं जहां उन्हें स्थानांतरित किया जाता है।

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

यह पता चला है कि हमें निम्नलिखित चरण करने की आवश्यकता है:

• सूचकांक से पूछें (सस्ता)
• एक PSI (महंगा) बनाएँ
• प्रिंट लंबो टाइप (बहुत महंगा)

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

यहां, हालांकि, आप कोने को थोड़ा काट सकते हैं: ज्यादातर मामलों में हमें अंतिम प्रकार की आवश्यकता नहीं है। यदि केवल लैम्ब्डा को एक विधि से पारित नहीं किया जाता है जो इस स्थान पर एक सामान्य पैरामीटर लेता है, तो हम पैरामीटर हस्तक्षेप के अंतिम चरण से छुटकारा पा सकते हैं। यह कहें कि, यदि हमने लंबो टाइप java.util.function.Function<T, R> दिया है, तो हम प्रतिस्थापन मापदंडों T और R के मूल्यों की गणना नहीं कर सकते हैं: और इसलिए यह स्पष्ट है कि इसे खोज परिणाम पर लौटना है या नहीं। हालांकि यह इस तरह से एक विधि को बुलाते समय काम नहीं करेगा:

 static <T> void doSmth(Class<T> aClass, T value) {} 

इस विधि को इस तरह कहा जा सकता है: doSmth(Runnable.class, () -> {}) । फिर मेमने के प्रकार को T रूप में प्रदर्शित किया जाएगा, और आपको वैसे भी स्थानापन्न करना होगा। लेकिन यह एक दुर्लभ मामला है। इसलिए, यह बचाने के लिए निकला, लेकिन 10% से अधिक नहीं। समस्या का हल मूल रूप से नहीं है।

एक और विचार: यदि सटीक प्रकार का अनुमान जटिल है, तो चलो एक अनुमानित निष्कर्ष बनाते हैं। इसे केवल मिटाए गए प्रकारों पर काम करने दें और प्रतिबंधों के सेट को कम न करें, जैसा कि विनिर्देश में लिखा गया है, लेकिन बस कॉल की श्रृंखला का पालन करें। जब तक मिटाए गए प्रकार में सामान्य पैरामीटर शामिल नहीं होते हैं, तब तक सब कुछ ठीक है। उदाहरण के लिए, ऊपर दिए गए उदाहरण से धारा लें और निर्धारित करें कि क्या अंतिम StringConsumer हमारे StringConsumer लागू करता है:

• list चर -> प्रकार java.util.List
• List.stream() विधि - List.stream() java.util.stream.Stream प्रकार
• Stream.filter(...) विधि → java.util.stream.Stream टाइप करें। इसके अलावा, हम filter तर्कों पर भी नज़र नहीं डालते हैं, क्या अंतर है
• Stream.map(...) विधि - Stream.map(...) java.util.stream.Stream प्रकार, इसी तरह
• Stream.forEach(...) विधि → ऐसी एक विधि है, इसका पैरामीटर Consumer प्रकार का है, जो स्पष्ट रूप से, StringConsumer नहीं है।

ठीक है, उन्होंने पूर्ण प्रकार के अनुमान के बिना किया। इस तरह के एक सरल दृष्टिकोण के साथ, हालांकि, अतिभारित तरीकों में भाग लेना आसान है। यदि हम पूरी तरह से अनुमान नहीं लगाते हैं, तो आप सही ओवरलोड संस्करण का चयन नहीं कर सकते। यद्यपि नहीं, यह कभी-कभी संभव होता है यदि विधि मापदंडों की संख्या भिन्न होती है। उदाहरण के लिए:

 CompletableFuture.supplyAsync(Foo::bar, myExecutor).thenRunAsync(s -> list.add(s)); 

यहां हम आसानी से समझ सकते हैं

• दो CompletableFuture.supplyAsync विधियाँ हैं, लेकिन एक में एक तर्क होता है और दूसरे में दो लगते हैं, इसलिए एक को दो चुनें। यह एक CompletableFuture देता है।
• thenRunAsync विधियां भी दो हैं, और उनमें से आप उसी तरह चुन सकते हैं जो एक तर्क लेता है। संबंधित पैरामीटर टाइप Runnable , जिसका अर्थ है कि यह StringConsumer नहीं है।

यदि कई विधियाँ एक ही पैरामीटर को स्वीकार करती हैं, या कुछ के पास पैरामीटर्स की संख्या है और उपयुक्त भी दिखती है, तो आपको सभी विकल्पों पर नज़र रखनी होगी। लेकिन अक्सर यह डरावना भी नहीं होता है। उदाहरण के लिए:

 new StringBuilder().append(foo).append(bar).chars().forEach(s -> list.add(s)); 

• new StringBuilder() स्पष्ट रूप से java.lang.StringBuilder बनाता है। डिजाइनरों के लिए, हम अभी भी लिंक की अनुमति देते हैं, लेकिन यहां जटिल प्रकार के अनुमान की आवश्यकता नहीं है। भले ही new Foo<>(x, y, z) , हम विशिष्ट मापदंडों के मूल्यों को प्रदर्शित नहीं करते हैं, हम केवल Foo में रुचि रखते हैं।
• StringBuilder.append विधियाँ हैं जो एक तर्क लेती हैं, लेकिन वे सभी प्रकार java.lang.StringBuilder वापस कर देती java.lang.StringBuilder , इसलिए यह महत्वपूर्ण नहीं है कि किस प्रकार के foo और bar ।
• StringBuilder.chars विधि एक है और java.util.stream.IntStream देता है।
• IntStream.forEach विधि एक है और IntConsumer प्रकार को स्वीकार करती है।

यहां तक ​​कि अगर कई विकल्प कहीं रहते हैं, तो आप उन सभी को ट्रैक कर सकते हैं। उदाहरण के लिए, लैम्ब्डा का प्रकार ForkJoinPool.getInstance().submit(...) या ForkJoinPool.getInstance().submit(...) करने ForkJoinPool.getInstance().submit(...) हो सकता है, लेकिन अगर हम किसी तीसरे की तलाश कर रहे हैं, तो हम अभी भी लैम्बडा को त्याग नहीं सकते हैं।

एक अप्रिय स्थिति तब होती है जब एक विधि एक सामान्य पैरामीटर लौटाती है। फिर प्रक्रिया टूट जाती है और आपको पूर्ण प्रकार का इंजेक्शन चलाना पड़ता है। हालाँकि, हमने एक मामले का समर्थन किया। यह मेरी स्ट्रीमएक्स लाइब्रेरी में अच्छी तरह से दिखाई देता है, जिसमें एक अमूर्त वर्ग है AbstractStreamEx<T, S extends AbstractStreamEx<T, S>> जिसमें S filter(Predicate<? super T> predicate) जैसी विधियाँ हैं। आमतौर पर लोग एक विशिष्ट वर्ग के साथ काम करते हैं StreamEx<T> extends AbstractStreamEx<T, StreamEx<T>> । इस स्थिति में, आप प्रकार पैरामीटर का प्रतिस्थापन कर सकते हैं और पता लगा सकते हैं कि S = StreamEx ।

खैर, कई मामलों में हमें बहुत महंगे प्रकार के अनुमानों से छुटकारा मिला। लेकिन हमने पीएसआई के निर्माण के साथ कुछ नहीं किया। किसी फ़ाइल को पांच सौ लाइनों में पार्स करने के लिए शर्म की बात यह है कि यह पता लगाने के लिए कि लाइन 480 में लंबोदर उसकी क्वेरी के लायक नहीं है। आइये अपनी स्ट्रीम पर वापस आते हैं:

 list.stream() .filter(s -> StringUtil.isNonEmpty(s)) .map(s -> s.trim()) .forEach(s -> list.add(s)); 

यदि list एक स्थानीय चर, विधि पैरामीटर या वर्तमान कक्षा में क्षेत्र है, तो पहले से ही अनुक्रमण चरण में हम इसकी घोषणा पा सकते हैं और स्थापित कर सकते हैं कि प्रकार का छोटा नाम है
List । तदनुसार, अंतिम लंबो के लिए सूचकांक में हम निम्नलिखित जानकारी डाल सकते हैं:

इस लैम्ब्डा का प्रकार एक तर्क से forEach विधि का पैरामीटर प्रकार है, जिसे एक तर्क से map विधि के परिणाम पर कहा जाता है, एक तर्क से filter विधि के परिणाम पर, शून्य तर्क से stream विधि के परिणाम पर कहा जाता है, प्रकार List ऑब्जेक्ट पर बुलाया जाता है।

यह सभी जानकारी वर्तमान फ़ाइल पर उपलब्ध है, जिसका अर्थ है कि इसे सूचकांक में रखा जा सकता है। खोज के दौरान, हम सभी लैम्ब्डा के बारे में ऐसी जानकारी के लिए सूचकांक से पूछते हैं और पीएसआई के निर्माण के बिना लैम्ब्डा प्रकार को बहाल करने का प्रयास करते हैं। पहले आपको छोटी नाम List कक्षाओं के लिए एक वैश्विक खोज करनी होगी। बेशक, हम न केवल java.util.List , बल्कि java.awt.List या उपयोगकर्ता परियोजना के कोड से कुछ भी पाएंगे। इसके अलावा, हम इन सभी वर्गों को गलत प्रकार के समाधान की उसी प्रक्रिया में जमा करेंगे जो हमने पहले इस्तेमाल किया था। अक्सर अतिरिक्त कक्षाएं खुद को जल्दी से फ़िल्टर कर दी जाती हैं। उदाहरण के लिए, java.awt.List में कोई stream विधि नहीं stream , इसलिए इसे आगे नहीं रखा गया है। लेकिन यहां तक ​​कि अगर कुछ अतिविशिष्ट हमारे साथ अंत तक है और हम अपने लैम्ब्डा के प्रकार के लिए कई उम्मीदवार ढूंढते हैं, तो अच्छी संभावना है कि वे सभी खोज क्वेरी में फिट नहीं होंगे, और हम अभी भी एक पूर्ण पीएसआई बनाने से बचेंगे।

यह संभव है कि वैश्विक खोज बहुत महंगी हो (परियोजना में कई List वर्ग हैं), या तो श्रृंखला की शुरुआत एक फ़ाइल के संदर्भ में अनुमति नहीं है (जैसे, यह मूल वर्ग का क्षेत्र है), या श्रृंखला कहीं बाधित होगी क्योंकि विधि एक सामान्य पैरामीटर लौटाती है। तब हम तुरंत हार नहीं मानते हैं और अगले चिनिंग विधि पर वैश्विक खोज के साथ फिर से शुरुआत करने की कोशिश करते हैं। उदाहरण के लिए, map.get(key).updateAndGet(a -> a * 2) श्रृंखला के लिए, निम्न कथन सूचकांक में गया:

लैम्ब्डा का प्रकार updateAndGet विधि के एकमात्र पैरामीटर का प्रकार है, जिसे एक पैरामीटर के साथ get विधि के परिणाम पर कहा जाता है, टाइप Map के ऑब्जेक्ट पर कहा जाता है।

हमें भाग्यशाली होना चाहिए और परियोजना में केवल एक प्रकार का Map - java.util.Map । इसकी एक get(Object) विधि है, लेकिन दुर्भाग्य से यह जेनेरिक पैरामीटर V लौटाता है V फिर हम श्रृंखला को छोड़ देते हैं और एक पैरामीटर (सूचकांक का उपयोग करते हुए, निश्चित रूप से) के साथ updateAndGet विधि के लिए वैश्विक रूप से देखते हैं। AtomicInteger , प्रोजेक्ट में केवल तीन ऐसे तरीके हैं, जैसे कि AtomicInteger , AtomicLong और AtomicReference AtomicLong AtomicInteger , AtomicLong और AtomicReference के मापदंडों के साथ। यदि हम किसी अन्य प्रकार की तलाश कर रहे हैं, तो हमें पता चला कि यह मेमना फिट नहीं है और पीएसआई का निर्माण नहीं किया जा सकता है।

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

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

मैंने कहा "हो सकता है" क्योंकि, निश्चित रूप से, हम समय-समय पर इस खोज पर वापस आते हैं और इसे गति देने की कोशिश करते हैं। लेकिन यहां आपको धारा के विपरीत नहीं, बल्कि झरने के ऊपर भी जाना होगा। हम कोशिश करते हैं, लेकिन परियोजनाओं में लैम्ब्डा की संख्या बहुत तेज़ी से बढ़ रही है।