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