2009-02-24 18 views
11

तो, हर बार जब मैं एक लैम्ब्डा अभिव्यक्ति या एक विधि है कि मैं काफी सही नहीं मिला अंदर गुमनाम विधि लिखा है, मैं इसे ठीक करने के लिए पुन: संयोजित और पूरे आवेदन या इकाई परीक्षण ढांचे को पुनः आरंभ करने के लिए मजबूर कर रहा हूँ। यह गंभीर रूप से परेशान है, और मैं पहली बार इन संरचनाओं का उपयोग करके सहेजने से अधिक समय बर्बाद कर देता हूं। यह इतना बुरा है कि अगर मैं कर सकता हूं, तो मैं उनसे दूर रहने की कोशिश करता हूं, भले ही लिंक और लैम्ब्डा मेरे पसंदीदा सी # फीचर्स में से हैं।मैं ऐसी विधि को क्यों संपादित नहीं कर सकता जिसमें डीबगर में अज्ञात विधि हो?

मुझे लगता है कि यह एक अच्छा तकनीकी कारण है कि यह इस तरह क्यों है, और शायद कोई जानता है? इसके अलावा, क्या किसी को पता है कि यह वीएस -2010 में तय किया जाएगा?

धन्यवाद।

उत्तर

14

हां एक बहुत अच्छा कारण है कि आप ऐसा क्यों नहीं कर सकते हैं। सरल कारण लागत है। सी # (या वीबी) में इस सुविधा को सक्षम करने की लागत अत्यंत उच्च है।

एक लैम्ब्डा समारोह का संपादन ENC मुद्दों है कि वर्तमान ENC (Edit'n'Continue) वास्तुकला के साथ हल करने के लिए बहुत मुश्किल हो जाता के एक वर्ग की एक विशेष मामला है। अर्थात्, यह ENC करने के लिए बहुत मुश्किल है किसी भी विधि है जो जहां ENC निम्न में से एक है: -

  1. एक वर्ग
  2. संपादित करता के रूप में उत्पन्न करता है मेटाडाटा या एक सामान्य विधि

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

दूसरा मुद्दा सीएलआर ईएनसी आर्किटेक्चर में सख्त सीमा है। ऐसा कुछ नहीं है जो सी # (या वीबी) इस के आसपास काम करने के लिए कर सकता है।

दुर्भाग्यवश दुर्भाग्य से इन दोनों मुद्दों पर मारे गए। लघु संस्करण यह है कि एक लैम्ब्डा में ईएनसीएनिंग में मौजूदा वर्गों पर कई उत्परिवर्तन शामिल होते हैं (जो अन्य ईएनसी से उत्पन्न हो सकते हैं या नहीं)। बड़ी समस्या मौजूदा कोड अंतरिक्ष में नए कोड और मौजूदा बंद उदाहरणों के बीच मतभेदों को हल करने में आती है। इसके अलावा, लैम्बडास जेनरिक्स का उपयोग अन्य कोड की तुलना में बहुत अधिक है और समस्या # 2 दबाएं।

विवरण सुंदर बालों वाले हैं और सामान्य SO उत्तर के लिए थोड़ा सा शामिल हैं। मैंने इस विषय पर एक लंबा ब्लॉग पोस्ट लिखने पर विचार किया है। अगर मैं इसके चारों ओर घूमता हूं तो मैं इसे इस विशेष उत्तर में वापस जोड़ दूंगा।

+1

सीधे घोड़े के मुंह से। +1 –

+0

@ जोन हमने इस विषय पर कई आंतरिक बैठकें की हैं और मुझे इस प्रस्तुति को कई बार देना पड़ा है। मुझे वास्तव में इस विषय पर एक पूर्ण उड़ा दस्तावेज़ लिखने की जरूरत है। ब्लॉगिंग इसके लिए एक अच्छी जगह की तरह लगता है। उम्मीद है कि इसे वीएस के भविष्य के संस्करण में हल किया जाएगा। – JaredPar

+1

कृपया इसके बारे में एक ब्लॉग लिखें। – Eyvind

0

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

संपादित करें: क्यों यह काम नहीं करता के लिए के रूप में - आप पा सकते हैं कि यह कुछ lambdas नहीं बल्कि दूसरों के लिए काम करता है। लैम्ब्डा अभिव्यक्ति जो किसी भी चर को कैप्चर नहीं करती है (this समेत) एक निजी स्थैतिक चर में कैश की जाती है, ताकि प्रतिनिधि का केवल एक उदाहरण बनाया जा सके। कोड को बदलने का मतलब उस चर को फिर से शुरू करना है जो मुझे संदेहजनक दिलचस्प दुष्प्रभाव हो सकता है।

+0

मैं सहमत हूं ...., लेकिन यह सवाल का जवाब नहीं है। –

+0

मुझे पता था कि आपको जवाब पता होगा ;-) –

+0

आईएमओ कई प्रश्नों का उत्तर है कि दर्दनाक स्थिति में आने से बचें। –

1

Supported Code Changes की एक सूची के अनुसार, आप नहीं क्षेत्रों मौजूदा प्रकार के लिए जोड़ सकते हैं। बेनामी विधियों को अजीब-नामित कक्षाओं में वर्गीकृत किया गया है (थोडा <>_c__DisplayClass1), जो ठीक है: प्रकार। भले ही अनाम विधि में आपके संशोधनों में संलग्न चर के सेट को बदलने में शामिल न हो (जो कि मौजूदा वर्ग के फ़ील्ड्स को बदल देगा), मुझे लगता है कि अज्ञात तरीकों को संशोधित करना असंभव है।

+1

आपको स्वयं को प्रकट करने के लिए इस समस्या के लिए अज्ञात विधि को संशोधित करने की आवश्यकता नहीं है, यह एक विधि को संशोधित करने के लिए पर्याप्त है जो _contains_ एक अज्ञात विधि है, और ऐसा लगता है कि यहां तक ​​कि एक भी स्थान पर्याप्त है ... – Eyvind

1

यह थोड़ा शर्म की बात है कि इस सुविधा को आंशिक रूप से वीबी में समर्थित है लेकिन है नहीं सी #: http://msdn.microsoft.com/en-us/library/bb385795.aspx

सी # में एक ही व्यवहार को लागू करने वाले कार्यों में लैम्ब्डा भाव होते हैं के लिए 80% से दर्द के स्तर को कम करेगा, जहां हमें लैम्ब्डा अभिव्यक्तियों को संशोधित करने की आवश्यकता नहीं है और न ही किसी भी अभिव्यक्ति पर निर्भर करता है, और शायद "राक्षस लागत" के लिए नहीं।