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

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

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

यदि हम एक कार्यात्मक इंटरफ़ेस के साथ काम नहीं कर रहे हैं, तो तत्काल बच्चों को ढूंढना एक सरल कार्य है। Foo इंटरफ़ेस के कार्यान्वयन के लिए खोज करते समय, हमें उन सभी वर्गों को खोजने की आवश्यकता होती है जिनके पास implements Foo और implements Foo होने वाले इंटरफेस हैं जो extends Foo को extends Foo , साथ ही new Foo(...) {...} अनाम कक्षाएं। ऐसा करने के लिए, अग्रिम में प्रत्येक प्रोजेक्ट फ़ाइल का सिंटैक्स ट्री बनाने के लिए पर्याप्त है, संबंधित निर्माणों को ढूंढें, और उन्हें एक सूचकांक में जोड़ें। हालांकि, यहां एक org.example.evilcompany.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 का वास्तविक पूरी तरह से योग्य नाम क्या है। हमें कई पैकेजों की सामग्री पर गौर करना होगा। और प्रत्येक पैकेज को प्रोजेक्ट में कई स्थानों पर परिभाषित किया जा सकता है (उदाहरण के लिए, कई JAR फ़ाइलों में)। यदि हम इस फ़ाइल का विश्लेषण करते समय उचित प्रतीक रिज़ॉल्यूशन करते हैं, तो अनुक्रमण में बहुत समय लगेगा। लेकिन मुख्य समस्या यह है कि MyFoo.java पर बनाया गया सूचकांक अन्य फाइलों पर भी निर्भर करेगा। हम Foo इंटरफ़ेस की घोषणा को आगे org.example.foo , उदाहरण के लिए, MyFoo.java फ़ाइल में कुछ भी बदले बिना, org.example.bar पैकेज से org.example.bar पैकेज तक, लेकिन Foo का पूरी तरह से योग्य नाम बदल जाएगा।

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

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

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

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

कोड में अलग-अलग लंबोदर भाव हैं। उदाहरण के लिए:

 () -> {} // a certain mismatch: no parameters (a, b) -> a + b // a certain mismatch: two parameters s -> { return list.add(s); // a certain mismatch: a value is returned } s -> list.add(s); // a potential match 

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

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

चीजों को सीधे पाने के लिए, यह देखने लायक हो सकता है कि लैम्ब्डा के चारों ओर क्या है। कभी-कभी, यह काम करता है। उदाहरण के लिए:

 // declaration of a local variable or a field of different type Predicate<String> p = s -> list.add(s); // a different return type IntPredicate getPredicate() { return s -> list.add(s); } // assignment to a variable of a different type SomeType fn; fn = s -> list.add(s); // cast to a different type foo((SomeFunctionalType)(s -> list.add(s))); // declaration of a different type array 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 को बदल दिया है। अपनी खुद की एक कक्षा के साथ। खोज को इसे ध्यान में रखना चाहिए। और, स्वाभाविक रूप से, लैम्ब्डा का उपयोग न केवल मानक धाराओं में किया जाता है: ऐसे कई अन्य तरीके हैं, जिनसे उन्हें पारित किया जाता है।

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

तो, हमें निम्नलिखित कदम उठाने की आवश्यकता है:

• सूचकांक से पूछें (महंगा नहीं)
• पीएसआई बनाएँ (महंगा)
• लंबर प्रकार (बहुत महंगा)

जावा 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 लागू करता है:

• list चर -> java.util.List प्रकार
• List.stream() विधि → java.util.stream.Stream प्रकार
• Stream.filter(...) विधि -> java.util.stream.Stream प्रकार, हमें filter तर्क पर विचार करने की आवश्यकता नहीं है
• इसी तरह, 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(...) या Callable हो सकता है, और यदि हम किसी अन्य विकल्प की तलाश कर रहे हैं, तो भी हम इस लैम्ब्डा को छोड़ सकते हैं।

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

यही कारण है कि हमने कई मामलों के लिए महंगा प्रकार के अनुमान से छुटकारा पा लिया है। लेकिन हमने पीएसआई के निर्माण के साथ कुछ नहीं किया है। कोड की 500 लाइनों के साथ फ़ाइल को केवल यह पता लगाना निराशाजनक है कि लाइन 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 , इसलिए इसे बाहर रखा जाएगा। लेकिन भले ही कुछ अतिरेक रहता है और हम लंबोदर प्रकार के कई उम्मीदवारों को ढूंढते हैं, संभावना है कि उनमें से कोई भी खोज क्वेरी से मेल नहीं खाता है, और हम अभी भी पूर्ण PSI बनाने से बचेंगे।

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

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

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

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

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

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