এই প্রশ্নটি আমার ব্লগের বিষয় ছিল সেপ্টেম্বর 20, 2010 এ । জোশ এবং চাদের উত্তর ("তারা কোনও মূল্য যুক্ত করে না কেন তবে এগুলি কেন প্রয়োজন?" এবং "অতিরিক্ত কাজগুলি নির্মূল করতে") মূলত সঠিক। মাংস যে কিছুটা আরও:
অবজেক্ট ইনিশিয়ালাইজারদের "বৃহত্তর বৈশিষ্ট্য" অংশ হিসাবে আপনাকে যুক্তি তালিকাটি এলিডে প্রবেশের অনুমতি দেওয়ার বৈশিষ্ট্যটি "মিষ্টিযুক্ত" বৈশিষ্ট্যগুলির জন্য আমাদের বারের সাথে দেখা করে। কিছু বিষয় আমরা বিবেচনা করেছি:
- নকশা এবং স্পেসিফিকেশন ব্যয় কম ছিল
- আমরা যেভাবে যাইহোক অবজেক্ট তৈরি পরিচালনা করে এমন পার্সার কোডটি ব্যাপকভাবে পরিবর্তন করতে যাচ্ছিলাম; বৃহত বৈশিষ্ট্যের ব্যয়ের তুলনায় প্যারামিটার তালিকাটি optionচ্ছিক করে তোলার অতিরিক্ত উন্নয়ন ব্যয় বেশি ছিল না
- বৃহত্তর বৈশিষ্ট্যের ব্যয়ের তুলনায় পরীক্ষার বোঝা তুলনামূলকভাবে কম ছিল
- ডকুমেন্টেশন বোঝা তুলনামূলকভাবে সামান্য ছিল ...
- রক্ষণাবেক্ষণ ভার কম হবে বলে আশা করা হয়েছিল; বছর বছরগুলিতে এই বৈশিষ্ট্যটিতে যে কোনও বাগ রিপোর্ট করা হয়েছে সেগুলি আমি স্মরণ করতে পারি না।
- বৈশিষ্ট্যটি এই অঞ্চলে ভবিষ্যতের বৈশিষ্ট্যগুলির জন্য অবিলম্বে কোনও সুস্পষ্ট ঝুঁকি তৈরি করে না। (আমরা শেষটি যা করতে চাই তা হ'ল এখন একটি সস্তার, সহজ বৈশিষ্ট্য তৈরি করা যা ভবিষ্যতে আরও বেশি আকর্ষণীয় বৈশিষ্ট্যটি প্রয়োগ করা আরও শক্ত করে তোলে))
- বৈশিষ্ট্যটি ভাষাটির শব্দাবাত, ব্যাকরণের বা শব্দার্থবিজ্ঞানের বিশ্লেষণে কোনও নতুন অস্পষ্টতা যুক্ত করে না। এটি টাইপ করার সময় আইডিইয়ের "ইন্টেলিজেন্স" ইঞ্জিন দ্বারা সম্পাদিত "আংশিক প্রোগ্রাম" বিশ্লেষণের ধরণের জন্য কোনও সমস্যা তৈরি করে না। ইত্যাদি।
- বৃহত্তর অবজেক্টের সূচনা বৈশিষ্ট্যের জন্য বৈশিষ্ট্যটি একটি সাধারণ "মিষ্টি স্পট" হিট করে; সাধারণত আপনি যদি কোনও অবজেক্ট ইনিশিয়ালাইজার ব্যবহার করছেন তবে এটি অবশ্যই অবিকল কারণ কারণ অবজেক্টের কনস্ট্রাক্টর আপনাকে যে বৈশিষ্ট্যগুলি চান তা সেট করতে দেয় না। এ জাতীয় অবজেক্টগুলির পক্ষে কেবল "সম্পত্তি ব্যাগ" হওয়া খুব সাধারণ, যার প্রথম স্থানে কর্টারে কোনও প্যারামিটার নেই।
তারপরে আপনি কেন কোনও অবজেক্ট আরম্ভকারী নেই এমন কোনও অবজেক্ট ক্রিয়েশন এক্সপ্রেশনর ডিফল্ট কনস্ট্রাক্টর কলটিতে খালি বন্ধনী optionচ্ছিক করেন নি ?
উপরের মানদণ্ডগুলির তালিকায় আবার দেখুন। এর মধ্যে একটি হ'ল এই পরিবর্তনটি কোনও প্রোগ্রামের লেক্সিকাল, ব্যাকরণগত বা শব্দার্থক বিশ্লেষণে কোনও নতুন অস্পষ্টতা প্রবর্তন করে না। আপনার প্রস্তাবিত পরিবর্তনটি একটি অর্থ বিশ্লেষণ অস্পষ্টতার পরিচয় দেয় :
class P
{
class B
{
public class M { }
}
class C : B
{
new public void M(){}
}
static void Main()
{
new C().M(); // 1
new C.M(); // 2
}
}
লাইন 1 একটি নতুন সি তৈরি করে, ডিফল্ট কনস্ট্রাক্টরকে কল করে এবং তারপরে নতুন অবজেক্টে উদাহরণ পদ্ধতি এমকে কল করে। লাইন 2 বিএম এর একটি নতুন উদাহরণ তৈরি করে এবং এটির ডিফল্ট কনস্ট্রাক্টরকে কল করে। যদি লাইন 1 এর প্রথম বন্ধনীগুলি alচ্ছিক হয় তবে লাইন 2টি দ্বিধাগ্রস্ত হবে। তারপরে আমাদের দ্ব্যর্থহীনতার সমাধান করার জন্য একটি আইন নিয়ে আসতে হবে; আমরা এটিকে ত্রুটি করতে পারি না কারণ এটি তখন একটি ব্রেকিং পরিবর্তন হতে পারে যা বিদ্যমান আইনি সি # প্রোগ্রামকে একটি ভাঙ্গা প্রোগ্রামে পরিবর্তন করে।
সুতরাং নিয়মটি খুব জটিল হতে হবে: মূলত: প্রথম বন্ধনীগুলি কেবলমাত্র ক্ষেত্রে alচ্ছিক যেখানে তারা অস্পষ্টতার পরিচয় দেয় না। অস্পষ্টতার পরিচয় দেওয়া সমস্ত সম্ভাব্য কেস বিশ্লেষণ করতে হবে এবং সেগুলি সনাক্ত করার জন্য সংকলকটিতে কোড লিখতে হবে।
সেই আলোকে, ফিরে যান এবং আমি যে সমস্ত ব্যয় উল্লেখ করেছি তা দেখুন। তাদের মধ্যে এখন কত বড় হয়? জটিল বিধিগুলির বৃহত ডিজাইন, স্পেক, বিকাশ, পরীক্ষা এবং ডকুমেন্টেশন ব্যয় রয়েছে। জটিল বিধিগুলি ভবিষ্যতে বৈশিষ্ট্যগুলির সাথে অপ্রত্যাশিত মিথস্ক্রিয়ায় সমস্যা হওয়ার সম্ভাবনা অনেক বেশি।
সব কিসের জন্য? একটি ক্ষুদ্র গ্রাহক সুবিধা যা ভাষায় কোনও নতুন প্রতিনিধিত্বমূলক শক্তি যোগ করে না, তবে ক্রেজি কর্নারের কেসগুলিকে কেবল "গোটচা" করার জন্য অপেক্ষা করছে এমন কিছু দরিদ্র অনর্থক আত্মা যারা এটির মধ্যে চলে। এর মতো বৈশিষ্ট্যগুলি তত্ক্ষণাত্ কাটা হয়ে যায় এবং "এটি কখনও করবেন না" তালিকায় রাখুন।
আপনি কীভাবে সেই নির্দিষ্ট অস্পষ্টতা নির্ধারণ করলেন?
এটি সঙ্গে সঙ্গে পরিষ্কার ছিল; বিন্দুযুক্ত নাম কখন প্রত্যাশিত হবে তা নির্ধারণের জন্য আমি সি # তে নিয়মের সাথে বেশ পরিচিত।
নতুন বৈশিষ্ট্যটি বিবেচনা করার সময় আপনি কীভাবে এটি নির্ধারণ করবেন যে এটি কোনও দ্বিধাদ্বন্দ্ব ঘটায় কিনা? হাতে, আনুষ্ঠানিক প্রমাণ দ্বারা, মেশিন বিশ্লেষণ করে, কী?
সব তিনটি. আমি উপরে যেমন করেছিলাম তেমন বেশিরভাগ ক্ষেত্রে আমরা কেবল এটিতে ফটকা এবং নুডল দেখি। উদাহরণস্বরূপ, ধরুন আমরা সি # তে একটি নতুন উপসর্গ অপারেটর যুক্ত করতে চেয়েছিলাম "ফ্রব":
x = frob 123 + 456;
(আপডেট: frobঅবশ্যই await; এখানে বিশ্লেষণগুলি মূলত সেই বিশ্লেষণটি যা ডিজাইনের দল যুক্ত করার পরে গিয়েছিলawait )
"ফ্রব" এখানে "নতুন" বা "++" এর মতো - এটি কোনও প্রকারের প্রকাশের আগে আসে। আমরা কাঙ্ক্ষিত নজির এবং সাহসীকরণ ইত্যাদি কাজ করব এবং তারপরে "প্রোগ্রামটির যদি ইতিমধ্যে কোনও প্রকার, ক্ষেত্র, সম্পত্তি, ইভেন্ট, পদ্ধতি, ধ্রুবক বা স্থানীয় নামে পরিচিত ফ্রব থাকে তবে কী হবে?" এটি তত্ক্ষণাত এমন মামলার দিকে পরিচালিত করবে:
frob x = 10;
এর অর্থ কি "x = 10 এর ফলস্বরূপ ফ্রব অপারেশন করবেন, বা এক্স নামক ফ্রোব্যাকের একটি ভেরিয়েবল তৈরি করুন এবং এটির জন্য 10 নির্ধারণ করবেন?" (অথবা, যদি ফ্রোব্বিং কোনও ভেরিয়েবল উত্পন্ন করে, এটি 10 থেকে 10 এর জন্য একটি অ্যাসাইনমেন্ট হতে পারে frob xAfter সর্বোপরি, *x = 10;পার্স এবং বৈধ যদি xতা হয় int*))
G(frob + x)
এর অর্থ কি "এক্সের উপর আনরি প্লাস অপারেটরের ফলাফল ফ্রব" বা "এক্সে এক্সপ্রেশন ফ্রব যুক্ত করুন"?
ইত্যাদি। এই অস্পষ্টতাগুলি সমাধান করার জন্য আমরা বোধগম্যতার পরিচয় দিতে পারি। আপনি যখন "var x = 10;" বলবেন এটি দ্ব্যর্থক; এর অর্থ "x এর ধরণ নির্ধারণ করা" বা এর অর্থ "x প্রকারের বর্ণের" হতে পারে। সুতরাং আমাদের কাছে একটি হিউরিস্টিক রয়েছে: আমরা প্রথমে বর্ণ নামের একটি প্রকারটি অনুসন্ধান করার চেষ্টা করি এবং কেবলমাত্র যদি উপস্থিত না থাকে তবেই আমরা এক্স প্রকারটি অনুমান করি।
অথবা, আমরা সিন্ট্যাক্সটিকে এমন পরিবর্তন করতে পারি যাতে এটি অস্পষ্ট না হয়। যখন তারা সি # 2.0 ডিজাইন করেছিলেন তাদের এই সমস্যাটি ছিল:
yield(x);
এর অর্থ কি "একটি আয়রকের মধ্যে ফলন x" বা "আর্গুমেন্ট x দিয়ে ফলন পদ্ধতিটি কল করবেন?" এটি পরিবর্তন করে
yield return(x);
এটা এখন দ্ব্যর্থহীন।
কোনও অবজেক্ট ইনিশিয়ালাইজারে alচ্ছিক প্যারেন্সের ক্ষেত্রে দ্বিধাগুলি প্রবর্তিত হয়েছে কিনা তা যুক্তিযুক্ত হওয়া সহজ কারণ কারণ যে পরিস্থিতিতে যেটি starts দিয়ে শুরু হয় তা পরিচয় করিয়ে দেওয়া জাতির সংখ্যা খুব অল্প । মূলত কেবলমাত্র বিভিন্ন বিবৃতি প্রসঙ্গ, বিবৃতি ল্যাম্বডাস, অ্যারে আরম্ভকারী এবং এটি সম্পর্কে। সমস্ত মামলার মাধ্যমে যুক্তি দেখাতে এবং দেখায় যে কোনও অস্পষ্টতা নেই easy আইডিই দক্ষ থাকে কিনা তা নিশ্চিত করা কিছুটা শক্ত তবে খুব বেশি ঝামেলা ছাড়াই করা যেতে পারে।
স্পেকের সাথে এই ধরণের ফিডলিং সাধারণত পর্যাপ্ত। এটি যদি একটি বিশেষত বৈশিষ্ট্যযুক্ত বৈশিষ্ট্য হয় তবে আমরা ভারী সরঞ্জামগুলি টেনে আনি। উদাহরণস্বরূপ, লিনকিউ ডিজাইন করার সময়, সংকলক ছেলেগুলির মধ্যে একটি এবং উভয়ই পার্সার তত্ত্বের পটভূমি রয়েছে এমন আইডিই গাইস একটি পার্সার জেনারেটর তৈরি করেছিলেন যা অস্পষ্টতার সন্ধানের ব্যাকরণগুলির বিশ্লেষণ করতে পারে এবং তারপরে অনুসন্ধানের বোধগম্যতার জন্য প্রস্তাবিত সি # গ্রামার খাওয়ানো হয়েছিল ; এমনটি করার ফলে অনেকগুলি ক্ষেত্রেই দেখা গেছে যেখানে প্রশ্নগুলি অস্পষ্ট ছিল।
অথবা, যখন আমরা সি # 3.0 তে ল্যাম্বডাসে প্রকারভেদ প্রকারের অনুগ্রহ করেছিলাম তখন আমরা আমাদের প্রস্তাবগুলি লিখেছিলাম এবং তারপরে সেগুলি কেমব্রিজের মাইক্রোসফ্ট রিসার্চে পাঠিয়েছিলাম যেখানে ভাষা দলগুলি সেখানে আনুষ্ঠানিক প্রমাণটি প্রমাণ করার পক্ষে যথেষ্ট ছিল যে প্রকার অনুমানের প্রস্তাবটি ছিল তাত্ত্বিকভাবে শব্দ।
সি # তে আজ কি অস্পষ্টতা আছে?
অবশ্যই।
G(F<A, B>(0))
সি # 1 এ এর অর্থ কী তা পরিষ্কার। এটি যেমন:
G( (F<A), (B>0) )
অর্থাৎ এটি দুটি আর্গুমেন্টের সাথে জি কে কল দেয় যেগুলি বুল। সি # 2-এ, এর অর্থ সি # 1 এর অর্থ কী হতে পারে তবে এর অর্থ "জেনেরিক পদ্ধতিতে F 0 পাস করুন যা টাইপ পরামিতি A এবং B গ্রহণ করে এবং তারপরে এফ এর ফলকে G তে পাস করবে"। আমরা পার্সারে একটি জটিল হিউরিস্টিক যুক্ত করেছি যা এটি নির্ধারণ করে যে আপনি সম্ভবত দুটি ক্ষেত্রে কে বোঝাতে চেয়েছেন।
একইভাবে, C # 1.0 তেও বর্ণগুলি দ্ব্যর্থহীন are
G((T)-x)
এটি কি "কাস্ট-এক্স থেকে টি" বা "টি থেকে এক্স বিয়োগ করে"? আবার, আমাদের কাছে একটি হিউরিস্টিক রয়েছে যা ভাল অনুমান করে।