আমি আজ একটি টুইট পড়েছি যাতে বলা হয়েছে:
জাভা ব্যবহারকারীরা টাইপ মোছা সম্পর্কে অভিযোগ করার সময় মজার বিষয় হয়, যা জাভা সঠিক হয়েছিল এবং এটি ভুল হয়ে যাওয়া সমস্ত বিষয় উপেক্ষা করে।
এইভাবে আমার প্রশ্নটি হ'ল:
জাভা টাইপ মুছে ফেলার সুবিধা আছে? প্রযুক্তিগত বা প্রোগ্রামিং শৈলীর কী কী সুবিধা রয়েছে (সম্ভবত) পিছনের সামঞ্জস্যতা এবং রানটাইম পারফরম্যান্সের জন্য জেভিএম বাস্তবায়ন অগ্রাধিকার ব্যতীত অন্য প্রস্তাব দেয়?
উত্তর:
এখনও পর্যন্ত অনেক উত্তর টুইটার ব্যবহারকারীর সাথে অত্যধিক উদ্বিগ্ন। ম্যাসেঞ্জারে নয় বার্তাগুলির প্রতি মনোনিবেশ রাখতে এটি সহায়ক। এখানে এখনও উল্লেখ করা অংশগুলি সহ একটি মোটামুটি সামঞ্জস্যপূর্ণ বার্তা রয়েছে:
জাভা ব্যবহারকারীরা টাইপ মোছা সম্পর্কে অভিযোগ করার সময় মজার বিষয় হয়, যা জাভা সঠিক হয়েছিল এবং এটি ভুল হয়ে যাওয়া সমস্ত বিষয় উপেক্ষা করে।
আমি বিশাল সুবিধাগুলি পাই (যেমন প্যারামিট্রিকটি) এবং শূন্য ব্যয় (কথিত ব্যয়টি কল্পনার সীমা)।
নতুন টি একটি ভাঙা প্রোগ্রাম। এটি "সমস্ত প্রস্তাবনা সত্য" এই দাবির পক্ষে বিস্ময়কর। আমি এর মধ্যে বড় নই।
এই টুইটগুলি এমন একটি দৃষ্টিকোণ প্রতিফলিত করে যা আমরা মেশিনকে কিছু করতে পারি কিনা সে বিষয়ে আগ্রহী নয় , তবে আমরা কীভাবে মেশিনটিকে আমাদের চাই কিছু করতে পারে তা যুক্তিযুক্ত কিনা তা আরও বেশি। ভাল যুক্তি একটি প্রমাণ। প্রুফগুলি আনুষ্ঠানিক স্বরলিপি বা কিছু কম ফর্মালতে নির্দিষ্ট করা যেতে পারে। স্পেসিফিকেশন ভাষা নির্বিশেষে এগুলি অবশ্যই স্পষ্ট এবং কঠোর হতে হবে। অনানুষ্ঠানিক স্পেসিফিকেশন সঠিকভাবে গঠন করা অসম্ভব না, তবে প্রায়শই ব্যবহারিক প্রোগ্রামিংয়ে ত্রুটিযুক্ত হয়। আমরা অনানুষ্ঠানিক যুক্তিযুক্ত সমস্যাগুলির সমাধান করতে স্বয়ংক্রিয় এবং অনুসন্ধানের পরীক্ষার মতো প্রতিকার দিয়ে শেষ করি। এটি এই বলে না যে পরীক্ষার অভ্যন্তরীণভাবে একটি খারাপ ধারণা, তবে উদ্ধৃত টুইটার ব্যবহারকারী আরও অনেক ভাল উপায় আছে বলে পরামর্শ দিচ্ছেন।
সুতরাং আমাদের লক্ষ্য হ'ল সঠিক প্রোগ্রামগুলি যা আমরা পরিষ্কারভাবে এবং কঠোরতার সাথে এমনভাবে যুক্তি করতে পারি যা মেশিনটি কীভাবে প্রোগ্রামটি বাস্তবায়িত করবে with এটি যদিও একমাত্র লক্ষ্য নয়। আমরা আমাদের যুক্তিটিও চাই একটি ডিগ্রি প্রকাশের জন্য। উদাহরণস্বরূপ, আমরা কেবলমাত্র প্রচুর যুক্তি দিয়েই প্রকাশ করতে পারি। প্রথম-আদেশের যুক্তির মতো কিছু থেকে সর্বজনীন (∀) এবং অস্তিত্বের (∃) পরিমাণ নির্ধারণ করা ভাল।
টাইপ সিস্টেমগুলি দ্বারা এই লক্ষ্যগুলি খুব সুন্দরভাবে সম্বোধন করা যেতে পারে। কারি-হাওয়ার্ডের চিঠিপত্রের কারণে এটি বিশেষত স্পষ্ট । এই চিঠিপত্রটি প্রায়শই নিম্নলিখিত সাদৃশ্য দিয়ে প্রকাশ করা হয়: প্রবণতাগুলি প্রমাণ হিসাবে প্রকার হিসাবে প্রোগ্রামগুলি হয়।
এই চিঠিপত্র কিছুটা গভীর। আমরা যৌক্তিক অভিব্যক্তি নিতে পারি এবং প্রকারের চিঠির মাধ্যমে তাদের অনুবাদ করতে পারি। তারপরে যদি আমাদের একই ধরণের স্বাক্ষরযুক্ত একটি প্রোগ্রাম থাকে যা সংকলন করে, আমরা প্রমাণিত করেছি যে লজিক্যাল এক্সপ্রেশনটি সর্বজনীন সত্য (একটি টোটোলজি)। কারণ এই চিঠিপত্রটি দ্বি-মুখী। প্রকার / প্রোগ্রাম এবং উপপাদ্য / প্রুফ ওয়ার্ল্ডগুলির মধ্যে রূপান্তরটি যান্ত্রিক এবং অনেক ক্ষেত্রে স্বয়ংক্রিয়ভাবে তৈরি হতে পারে।
কারি-হাওয়ার্ড একটি প্রোগ্রামের স্পেসিফিকেশনগুলির সাথে আমরা কী করতে চাই তাতে দুর্দান্ত অভিনয় করে।
এমনকি কারি-হাওয়ার্ড বোঝার পরেও কিছু লোক সহজেই কোনও টাইপ সিস্টেমের মূল্য বর্জন করা সহজ মনে করে
প্রথম পয়েন্টটি সম্পর্কে, সম্ভবত IDE গুলি জাভা টাইপ সিস্টেমের সাথে কাজ করার জন্য যথেষ্ট সহজ করে তোলে (এটি অত্যন্ত বিষয়গত)।
দ্বিতীয় বিষয়টির বিষয়ে, জাভা প্রায় প্রথম অর্ডার যুক্তির সাথে মিলিত হয়। জেনেরিক্স সর্বজনীন মাপদণ্ডের সমতুল্য টাইপ সিস্টেম ব্যবহার করে। দুর্ভাগ্যক্রমে, ওয়াইল্ডকার্ডগুলি আমাদের অস্তিত্বের পরিমাপের একটি ছোট অংশ দেয়। তবে সর্বজনীন মাপদণ্ডটি বেশ ভাল শুরু। সমস্ত সম্ভাব্য তালিকাগুলির List<A>জন্য সর্বজনীনভাবে কাজ করার জন্য এটি বলতে সক্ষম হওয়ায় এটি খুব ভাল কারণ এ সম্পূর্ণরূপে নিয়ন্ত্রণহীন। এটি টুইটার ব্যবহারকারী "প্যারামিট্রিকটি" এর সাথে সম্মানের সাথে কী কথা বলছে বাড়ে।
প্যারামিট্রিকটির বিষয়ে প্রায়শই একটি উদ্ধৃত কাগজ হ'ল ফ্রিপ ওয়েডলারের উপপাদাগুলি বিনামূল্যে! । এই কাগজটি সম্পর্কে মজার বিষয়টি হ'ল একমাত্র ধরণের স্বাক্ষর থেকে, আমরা কিছু খুব আকর্ষণীয় আক্রমণকারী প্রমাণ করতে পারি। যদি আমরা এই আক্রমণকারীদের জন্য স্বয়ংক্রিয় পরীক্ষাগুলি লিখি তবে আমরা আমাদের সময়কে অনেক বেশি অপচয় করব। উদাহরণস্বরূপ, List<A>একা স্বাক্ষর টাইপ থেকেflatten
<A> List<A> flatten(List<List<A>> nestedLists);
আমরা যে কারণ করতে পারেন
flatten(nestedList.map(l -> l.map(any_function)))
≡ flatten(nestList).map(any_function)
এটি একটি সহজ উদাহরণ, এবং আপনি সম্ভবত এটি অনানুষ্ঠানিকভাবে সম্পর্কে যুক্তিযুক্ত হতে পারেন, তবে এটি এমনকি আরও সুন্দর যখন আমরা এই জাতীয় প্রমাণগুলি প্রথাগতভাবে টাইপ সিস্টেম থেকে নিখরচায় পেয়ে যাই এবং সংকলক দ্বারা পরীক্ষা করা হয়।
ভাষা প্রয়োগের দৃষ্টিকোণ থেকে, জাভা এর জেনেরিকগুলি (যা সর্বজনীন ধরণের সাথে সামঞ্জস্যপূর্ণ) আমাদের প্রোগ্রামগুলি কী করে তার প্রমাণ পেতে ব্যবহৃত প্যারামিট্রিসিটিতে খুব ভারীভাবে খেল play এটি উল্লিখিত তৃতীয় সমস্যার দিকে যায়। প্রমাণ এবং নির্ভুলতার এই সমস্ত লাভের জন্য ত্রুটিগুলি ছাড়াই একটি শব্দ টাইপ সিস্টেম প্রয়োগ করা দরকার। জাভাতে অবশ্যই কিছু ভাষা বৈশিষ্ট্য রয়েছে যা আমাদের যুক্তিগুলি ছিন্ন করতে দেয়। এর মধ্যে রয়েছে তবে সীমাবদ্ধ নয়:
মুছে ফেলা জেনেরিকগুলি প্রতিবিম্বের সাথে সম্পর্কিত বিভিন্নভাবে। ক্ষয় না করে রানটাইমের তথ্য রয়েছে যা বাস্তবায়নের সাথে বহন করে যা আমরা আমাদের অ্যালগরিদমগুলি ডিজাইন করতে ব্যবহার করতে পারি। এর অর্থ কী তা স্থিরভাবে, যখন আমরা প্রোগ্রামগুলির বিষয়ে যুক্তি করি তখন আমাদের সম্পূর্ণ চিত্র থাকে না। প্রতিবিম্ব আমরা স্ট্যাটিকালি যে কারণে প্রমাণ করি তার যথার্থতার মারাত্মক হুমকি দেয়। এটা কোন কাকতালীয় প্রতিফলন বিভিন্ন ধরণের ত্রুটিও বাড়ে।
তাহলে কী কী উপায়গুলি যে মুছে ফেলা জেনেরিকগুলি "দরকারী" হতে পারে? টুইটে উল্লিখিত ব্যবহারগুলি বিবেচনা করুন:
<T> T broken { return new T(); }
টি-তে কোনও নো-আরগ কনস্ট্রাক্টর না থাকলে কী হবে? কিছু ভাষায় আপনি যা পান তা বাতিল। অথবা সম্ভবত আপনি নাল মান এড়িয়ে যান এবং সরাসরি একটি ব্যতিক্রম বাড়াতে যান (যা নাল মানগুলি যাইহোক নেতৃত্ব দেয়)। যেহেতু আমাদের ভাষা টিউরিং সম্পূর্ণ, কারণ কোন কলটি brokenনো-আর্গ নির্মাণকারীদের সাথে "নিরাপদ" প্রকারগুলিকে জড়িত করবে এবং কোনটি তা করবে না সে সম্পর্কে तर्क করা অসম্ভব । আমাদের কর্মসূচি সর্বজনীনভাবে কাজ করে তা আমরা হারিয়ে ফেলেছি।
সুতরাং আমরা যদি আমাদের প্রোগ্রামগুলি সম্পর্কে যুক্তি বোধ করতে চাই তবে আমাদের দৃ strongly়ভাবে পরামর্শ দেওয়া হচ্ছে যে ভাষা বৈশিষ্ট্যগুলি আমাদের যুক্তিকে দৃ strongly়ভাবে হুমকি দেয়। একবার আমরা এটি করি, তবে কেন রান টাইমে টাইপগুলি বাদ দিবেন না? তাদের দরকার নেই। কোনও ক্যাসেট ব্যর্থ হবে না বা অনুরোধের পরে যে পদ্ধতিগুলি অনুপস্থিত হতে পারে সে সন্তুষ্টির সাথে আমরা কিছু দক্ষতা এবং সরলতা পেতে পারি।
মুছে ফেলা যুক্তি উত্সাহ দেয়।
প্রকারগুলি এমন একটি পদ্ধতিতে প্রোগ্রাম লেখার জন্য ব্যবহৃত হয় যা সংকলকটিকে কোনও প্রোগ্রামের যথার্থতা পরীক্ষা করতে দেয়। একটি প্রকার একটি মান সম্পর্কিত প্রস্তাব - সংকলক যাচাই করে যে এই প্রস্তাবটি সত্য।
কোনও প্রোগ্রাম কার্যকর করার সময়, প্রকারের তথ্যের প্রয়োজন হবে না - এটি ইতিমধ্যে সংকলক দ্বারা যাচাই করা হয়েছে। সংকলকটি কোডটিতে অপটিমাইজেশন সম্পাদন করার জন্য এই তথ্যটি বাতিল করতে মুক্ত হওয়া উচিত - এটি দ্রুত চালানো, একটি ছোট বাইনারি তৈরি করা ইত্যাদি টাইপ পরামিতিগুলির ক্ষয় এটি সহজতর করে তোলে।
জাভা রান টাইম - প্রতিবিম্ব, উদাহরণ ইত্যাদি সময়ে টাইপ তথ্য জিজ্ঞাসা করার অনুমতি দিয়ে স্ট্যাটিক টাইপিং বিরতি দেয় এটি স্টাটিকালি যাচাই করা যায় না এমন প্রোগ্রামগুলি আপনাকে নির্মাণের অনুমতি দেয় - তারা টাইপ সিস্টেমটিকে বাইপাস করে। এটি স্থিতিশীল অপ্টিমাইজেশনের জন্য সুযোগগুলিও বাদ দেয়।
টাইপ প্যারামিটারগুলি মুছে ফেলার বিষয়টি এই ভুল প্রোগ্রামগুলির কিছু উদাহরণ নির্মাণে বাধা দেয়, তবে আরও বেশি ধরণের তথ্য মুছে ফেলা হলে এবং প্রতিচ্ছবি এবং বৈশিষ্ট্যগুলি সরানো হলে আরও ভুল প্রোগ্রামগুলি অনুমোদিত নয়।
ডেটা টাইপের "প্যারামিটারট্রিটি" এর সম্পত্তি ধরে রাখতে মুছে ফেলা গুরুত্বপূর্ণ important বলুন যে আমার কাছে উপাদান টাইপ টির উপরে তালিকার মতো "তালিকার" পরামিতি রয়েছে ie অর্থাৎ তালিকা <টি>। এই টাইপটি এমন একটি প্রস্তাব যে এই তালিকা টাইপটি কোনও প্রকার টিয়ের জন্য অভিন্নভাবে কাজ করে T টি যে একটি বিমূর্ত, সীমাহীন টাইপ পরামিতি এর অর্থ আমরা এই ধরণের সম্পর্কে কিছুই জানি না, তাই টি এর বিশেষ ক্ষেত্রে বিশেষ কিছু করার থেকে বিরত থাকে are
উদাহরণস্বরূপ বলুন আমার কাছে একটি তালিকা xs = asList ("3") আছে। আমি একটি উপাদান যুক্ত করেছি: xs.add ("q")। আমি ["3", "কিউ"] দিয়ে শেষ করছি। যেহেতু এটি প্যারাম্যাট্রিক, আমি ধরে নিতে পারি যে তালিকা xs = asList (7); xs.add (8) এর সাথে শেষ হয় [7,8] আমি টাইপ থেকে জানি যে এটি স্ট্রিংয়ের জন্য একটি জিনিস এবং ইন্টের জন্য একটি জিনিস করে না।
তদুপরি, আমি জানি যে List.add ফাংশন টি এর পাতলা বায়ুতে টির মান আবিষ্কার করতে পারে না। আমি জানি যে আমার অ্যাসলিস্টে ("3") এর সাথে "7" যুক্ত করা থাকলে, "3" এবং "7" মানগুলির মধ্যে একমাত্র সম্ভাব্য উত্তরগুলি তৈরি করা হত। তালিকায় একটি "2" বা "জেড" যুক্ত হওয়ার সম্ভাবনা নেই কারণ ফাংশনটি এটি নির্মাণ করতে অক্ষম হবে। এই অন্যান্য মানগুলির কোনওটিই যুক্ত করা বোধগম্য হবে না, এবং প্যারামিট্রিকটি এই ভুল প্রোগ্রামগুলি তৈরি হতে বাধা দেয়।
মূলত, মুছে ফেলা প্যারামিট্রিকটি লঙ্ঘনের কিছু উপায়কে বাধা দেয়, এভাবে ভুল প্রোগ্রামের সম্ভাবনাগুলি দূর করে, যা স্থির টাইপিংয়ের লক্ষ্য।
(যদিও আমি ইতিমধ্যে এখানে একটি উত্তর লিখেছি, দু'বছর পরে এই প্রশ্নের পুনর্বিবেচনা করছি বুঝতে পেরেছি এর উত্তর দেওয়ার আরও একটি আলাদা উপায় আছে, তাই আমি পূর্ববর্তী উত্তরটি অক্ষত রেখেছি এবং এটিকে যুক্ত করছি))
জাভা জেনেরিক্সে করা প্রক্রিয়াটি "টাইপ ইরেজোর" নামটির জন্য প্রাপ্য কিনা তা অত্যন্ত তর্কযোগ্য। যেহেতু জেনেরিক প্রকারগুলি মুছে ফেলা হয় না তবে তাদের কাঁচা অংশগুলির সাথে প্রতিস্থাপন করা হয়, তাই আরও ভাল পছন্দটি "টাইপ বিয়োগ" বলে মনে হয়।
সাধারণভাবে বোঝা অর্থে টাইপ মুছে ফেলার পঞ্চম বৈশিষ্ট্যটি রানটাইমটিকে অ্যাক্সেস করে এমন তথ্যের কাঠামোর সাথে "অন্ধ" করে স্ট্যাটিক টাইপ সিস্টেমের সীমানার মধ্যে থাকতে বাধ্য করছে। এটি সংকলককে সম্পূর্ণ শক্তি দেয় এবং এটি কেবল স্থিতিশীল প্রকারের ভিত্তিতে উপপাদাগুলি প্রমাণ করার অনুমতি দেয়। এটি কোডারের স্বাধীনতার ডিগ্রিগুলিকে সীমাবদ্ধ করে সাধারণ যুক্তিকে আরও শক্তি দিয়ে প্রোগ্রামারকে সহায়তা করে।
জাভা ধরণের মুছে ফেলা এটি অর্জন করে না — এটি সংকলককে পঙ্গু করে, যেমন এই উদাহরণটির মতো:
void doStuff(List<Integer> collection) {
}
void doStuff(List<String> collection) // ERROR: a method cannot have
// overloads which only differ in type parameters
(উপরের দুটি ঘোষণাগুলি মুছে ফেলার পরে একই পদ্ধতিতে স্বাক্ষর হয়ে যায়))
ফ্লিপ দিকে, রানটাইম এখনও কোনও বস্তুর ধরণ এবং এটি সম্পর্কে কারণ পরীক্ষা করতে পারে, তবে যেহেতু এর প্রকৃত প্রকারের অন্তর্দৃষ্টি ক্ষয় দ্বারা পঙ্গু হয়, স্থির ধরণের লঙ্ঘন অর্জন করা তুচ্ছ এবং প্রতিরোধ করা শক্ত।
জিনিসগুলিকে আরও সংশ্লেষিত করতে, মূল এবং মুছে ফেলা ধরণের স্বাক্ষরগুলি সহ-বিদ্যমান এবং সংকলনের সময় সমান্তরালে বিবেচনা করা হয়। এটি কারণ পুরো প্রক্রিয়াটি রানটাইম থেকে টাইপ তথ্য সরিয়ে ফেলার বিষয়ে নয়, তবে পিছনের সামঞ্জস্যতা বজায় রাখার জন্য জেনেরিক টাইপ সিস্টেমকে লিগ্যাসি কাঁচা টাইপ সিস্টেমে জুতো ছোঁড়ার বিষয়ে। এই মণি একটি সর্বোত্তম উদাহরণ:
public static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll)
( extends Objectমুছে ফেলা স্বাক্ষরের পিছনে সামঞ্জস্যতা রক্ষা করতে রিডানডেন্ট যুক্ত করতে হয়েছিল))
এখন, এই বিষয়টি মনে রেখে, আসুন এই উদ্ধৃতিটি আবার দেখা যাক:
জাভা ব্যবহারকারীরা টাইপ মোছা সম্পর্কে অভিযোগ করার সময় এটি মজার বিষয়, যা জাভা সঠিক হওয়ার একমাত্র জিনিস
জাভা ঠিক কী পেয়েছে? অর্থটি নির্বিশেষে এটিই কি শব্দটি? বিপরীতে নম্র intপ্রকারটি একবার দেখুন: কোনও রানটাইম টাইপ চেক কখনও করা হয় না, এমনকি সম্ভবও হয় না এবং কার্যকর করা সর্বদা নিখুঁতভাবে টাইপ-সেফ থাকে। সঠিকভাবে সম্পন্ন করার পরে এ জাতীয় ধরণটি কী রকম দেখাচ্ছে: আপনি জানেন না যে এটি সেখানে রয়েছে।
আমি এখানে যে জিনিসটি বিবেচনা করছি তা হ'ল ওওপি-র রানটাইম পলিমারফিজম মূলত রানটাইমের সময় ধরণের পুনর্বিবেচনার উপর নির্ভরশীল। যখন কোন ভাষা যার পশ্চাদমুখে রিফাইড ধরণের দ্বারা স্থিত হয় তার টাইপ সিস্টেমে একটি বড় বর্ধনের পরিচয় হয় এবং এটিকে মুছে ফেলার ভিত্তিতে স্থাপন করা হয়, তখন জ্ঞানীয় বিভেদ অনিবার্য পরিণতি। জাভা সম্প্রদায়ের ক্ষেত্রে ঠিক এটি ঘটেছে; এ কারণেই মুছে ফেলা এত বিতর্ককে আকৃষ্ট করেছে এবং শেষ পর্যন্ত জাভাতে ভবিষ্যতে প্রকাশে এটিকে পূর্বাবস্থায় ফেলার পরিকল্পনা রয়েছে কেন । জাভা ব্যবহারকারীদের সেই অভিযোগের মধ্যে মজার কিছু খুঁজে পাওয়াই হয় জাভার চেতনার একটি সৎ ভুল বোঝাবুঝি, বা একটি সচেতনভাবে অবজ্ঞাপূর্ণ রসিক bet
দাবিটি "মুছে ফেলা একমাত্র জাভা ঠিকই পেয়েছে" এই দাবিটি বোঝায় যে "রানটাইম টাইপের ফাংশন আর্গুমেন্টের বিরুদ্ধে গতিশীল প্রেরণের উপর ভিত্তি করে সমস্ত ভাষা মৌলিকভাবে ত্রুটিযুক্ত"। যদিও অবশ্যই তার নিজের উপর একটি বৈধ দাবি, এবং এক এমনকি জাভা সহ সব গলি ভাষায় বৈধ সমালোচনা হিসেবে বিবেচনা করা যেতে পারে, এটা নিজেই একটি কেঁদ্রগত বিন্দু যা থেকে দায়ের করতে পারবে না মূল্যায়ন এবং বৈশিষ্ট্য সমালোচনা জাভার অনুষঙ্গের মধ্যে , যেখানে রানটাইম পলিমরফিজম অ্যাকসিওমেটিক
সংক্ষেপে, যখন কেউ বৈধতা দিয়ে বলতে পারেন যে "টাইপ ইরেজোর হল ভাষা নকশায় যাওয়ার উপায়", জাভাতে টাইপ ইরেজোর সমর্থনকারী অবস্থানগুলি ভুলভাবে প্রতিস্থাপন করা হয়েছে কারণ এটি অনেক বেশি, এর চেয়ে অনেক দেরি এবং ইতিমধ্যে এমনকি historicalতিহাসিক মুহুর্তেও তাই ছিল যখন ওক সান দ্বারা আলিঙ্গন করেছিলেন এবং জাভা নামকরণ করেছিলেন।
স্থিতিশীল টাইপিং নিজেই প্রোগ্রামিং ভাষার নকশার যথাযথ দিক নির্দেশনা কিনা, এটি আমাদের প্রোগ্রামিংয়ের ক্রিয়াকলাপকে কী বলে মনে করে তার অনেক বেশি দার্শনিক প্রসঙ্গে খাপ খায় । একটি বিদ্যালয়ের চিন্তাভাবনা, গণিতের শাস্ত্রীয় traditionতিহ্য থেকে স্পষ্টভাবে প্রাপ্ত, প্রোগ্রামগুলিকে একটি গাণিতিক ধারণা বা অন্যান্য (প্রস্তাবনা, ফাংশন, ইত্যাদি) উদাহরণ হিসাবে দেখায়, তবে একটি সম্পূর্ণ ভিন্ন পদ্ধতির পন্থা রয়েছে, যা প্রোগ্রামিংকে একটি উপায় হিসাবে দেখায় মেশিনের সাথে কথা বলুন এবং এটি থেকে আমরা কী চাই তা ব্যাখ্যা করুন। এই দৃশ্যে প্রোগ্রামটি একটি গতিশীল, জৈবিকভাবে বর্ধনশীল সত্তা, একটি স্ট্যাটিকালি টাইপড প্রোগ্রামের সাবধানতার সাথে উত্সাহিত এডিফাইসের বিপরীতে একটি নাটকীয় বিপরীতে।
গতিশীল ভাষাগুলি সেই দিকের পদক্ষেপ হিসাবে বিবেচনা করা স্বাভাবিক বলে মনে হয়: প্রোগ্রামটির ধারাবাহিকতা নীচ থেকে উপরে উঠে আসে, অগ্রাধিকারের কোনও সীমাবদ্ধতা নেই যা এটিকে শীর্ষ-নীচে চাপিয়ে দেয়। এই দৃষ্টান্তটিকে প্রক্রিয়াটির মডেলিংয়ের এক ধাপ হিসাবে দেখা যেতে পারে যার মাধ্যমে আমরা, মানুষেরা আমরা যা হয়েছি উন্নয়ন এবং শেখার মাধ্যমে become
একই কথোপকথনে একই ব্যবহারকারীর পরবর্তী পোস্ট:
নতুন টি একটি ভাঙা প্রোগ্রাম। এটি "সমস্ত প্রস্তাবনা সত্য" এই দাবির পক্ষে বিস্ময়কর। আমি এর মধ্যে বড় নই।
(এটি অন্য ব্যবহারকারীর বক্তব্যের জবাবে ছিল, যথা - "এটি কিছু পরিস্থিতিতে 'নতুন টি'র চেয়ে ভাল হবে", ধারণাটি new T()ধরণের ক্ষয়জনিত কারণে অসম্ভব। "এটি বিতর্কযোগ্য - এমনকি যদি Tএখানে উপলব্ধ থাকত তবে রানটাইম, এটি একটি বিমূর্ত শ্রেণি বা ইন্টারফেস হতে পারে, বা এটি হতে পারে Void, বা এটি কোনও নো-আরগ কনস্ট্রাক্টরের অভাব হতে পারে, বা এর নো-আরগ কনস্ট্রাক্টর ব্যক্তিগত হতে পারে (উদাহরণস্বরূপ, কারণ এটি একটি সিঙ্গলটন শ্রেণি বলে মনে করা হচ্ছে), বা এর নো-আরগ কনস্ট্রাক্টর একটি যাচাইকৃত ব্যতিক্রম নির্দিষ্ট করতে পারে যা জেনেরিক পদ্ধতিটি ধরতে বা নির্দিষ্ট করে না - তবে এটিই ছিল পূর্বসূরি Reg নির্বিশেষে, এটি সত্য যে ক্ষয় না করে আপনি কমপক্ষে লিখতে পারতেন T.class.newInstance()যা এই সমস্যাগুলি পরিচালনা করে)))
এই মতামতটি, প্রকারভেদে প্রকারভেদগুলিতে বিভক্ত, প্রস্তাবিত যে প্রথাগত টাইপ তত্ত্বের ব্যবহারকারীর পটভূমি রয়েছে। (এস) তিনি সম্ভবত সম্ভবত "ডায়নামিক টাইপস" বা "রানটাইম টাইপস" পছন্দ করেন না এবং একটি জাভা বেছে নেবেন ঝর্ণা ছাড়াই instanceofএবং প্রতিচ্ছবি ইত্যাদি without (স্ট্যান্ডার্ড এমএল এর মতো ভাষার কথা ভাবুন, যার একটি খুব সমৃদ্ধ (স্ট্যাটিক) টাইপ সিস্টেম রয়েছে এবং যার গতিশীল শব্দার্থকতা কোনও ধরণের তথ্যের উপর নির্ভর করে না))
ব্যবহারকারী মনে রাখবেন যে, এটি ট্রোলিং করছে: যদিও সে সম্ভবত আন্তরিকভাবে টাইপ করা ভাষাগুলি (স্ট্যাটিকালি) পছন্দ করে, (গুলি) সে আন্তরিকতার সাথে অন্যদের বোঝানোর চেষ্টা করছে না । বরং আসল টুইটটির মূল উদ্দেশ্য ছিল যারা অসমত তাদেরকে ঠাট্টা করা, এবং যারা এই মতবিরোধ প্রকাশ করেছেন তাদের কিছু পরে, ব্যবহারকারী ফলো-আপ টুইট পোস্ট করেছেন যেমন "জাভা টাইপ ক্ষয় হওয়ার কারণ হ'ল ওয়েডলার এট আল কি জানেন? তারা জাভা ব্যবহারকারীদের মত নয় " দুর্ভাগ্যক্রমে, তিনি আসলে (গুলি) কী ভাবছেন তা খুঁজে পাওয়া শক্ত করে; তবে ভাগ্যক্রমে, এর সম্ভবত এটির অর্থ এটিও করা খুব গুরুত্বপূর্ণ নয়। তাদের মতামত প্রকৃত গভীরতা আছে তারা সাধারণত দানব যে অবলম্বন না বেশ এই বিষয়বস্তুতে-বিনামূল্যে।
একটি ভাল বিষয় হ'ল জেনারিকগুলি চালু করার সময় জেভিএম পরিবর্তন করার দরকার ছিল না। জাভা কেবল সংকলক স্তরে জেনেরিকগুলি প্রয়োগ করে।
কারণ মুছে ফেলা ভাল জিনিস হ'ল জিনিসগুলি এটি অসম্ভব করে তোলে তা ক্ষতিকারক। রানটাইমে টাইপ আর্গুমেন্টগুলির পরিদর্শন প্রতিরোধ করা প্রোগ্রামগুলি সম্পর্কে বোঝা এবং যুক্তি সহজ করে তোলে।
আমি যে পর্যবেক্ষণটি কিছুটা স্ব-স্বজ্ঞাত পেয়েছি তা হ'ল ফাংশনের স্বাক্ষরগুলি আরও জেনেরিক হয়, তখন তারা বুঝতে সহজ হয়। সম্ভাব্য বাস্তবায়নের সংখ্যা হ্রাস হওয়ায় এটি। এই স্বাক্ষর সহ একটি পদ্ধতি বিবেচনা করুন, যা আমরা একরকম জানি কোনও পার্শ্ব প্রতিক্রিয়া নেই:
public List<Integer> XXX(final List<Integer> l);
এই ফাংশনটির সম্ভাব্য বাস্তবায়নগুলি কী কী? খুব বেশি. এই ফাংশনটি কী করে তা সম্পর্কে আপনি খুব সামান্যই বলতে পারেন। এটি ইনপুট তালিকার বিপরীত হতে পারে। এটি একত্রে অন্তর্নির্মিত জুড়তে পারে, তাদের সংমিশ্রণ করতে পারে এবং অর্ধেক আকারের একটি তালিকা ফিরে আসতে পারে। কল্পনা করা যেতে পারে এমন আরও অনেক সম্ভাবনা রয়েছে। এখন বিবেচনা করুন:
public <T> List<T> XXX(final List<T> l);
এই ফাংশনটির কতগুলি বাস্তবায়ন রয়েছে? যেহেতু বাস্তবায়ন উপাদানগুলির ধরণটি জানতে পারে না, তাই বিপুল সংখ্যক বাস্তবায়ন এখন বাদ দেওয়া যায়: উপাদানগুলিকে একত্রিত করা যায় না, বা তালিকায় যুক্ত বা ফিল্টার আউট করা যায় না, ইত্যাদি। আমরা পরিচয় (তালিকার কোনও পরিবর্তন নেই), উপাদানগুলি বাদ দেওয়া বা তালিকার বিপরীতকরণের মতো বিষয়গুলিতে সীমাবদ্ধ। এই ফাংশনটি তার স্বাক্ষরের উপর ভিত্তি করে যুক্তি করা সহজ।
জাভা বাদে আপনি সর্বদা টাইপ সিস্টেমকে প্রতারণা করতে পারেন। যেহেতু সেই জেনেরিক পদ্ধতির প্রয়োগটি instanceofচেক এবং / বা কাস্টের মতো স্টাফকে স্বেচ্ছাসেবী প্রকারে ব্যবহার করতে পারে, তাই স্বাক্ষরের উপর ভিত্তি করে আমাদের যুক্তি সহজেই অকেজো হয়ে যায়। ফাংশন উপাদানগুলির ধরণটি পরীক্ষা করতে পারে এবং ফলাফলের উপর ভিত্তি করে যে কোনও সংখ্যক কাজ করতে পারে। যদি এই রানটাইম হ্যাকগুলি অনুমোদিত হয় তবে প্যারামিটারাইজড পদ্ধতিতে স্বাক্ষরগুলি আমাদের পক্ষে অনেক কম দরকারী হয়ে ওঠে।
যদি জাভাতে টাইপ মুছে ফেলা না হয় (অর্থাত্ টাইম আর্গুমেন্টগুলি রানটাইমের সময় পুনরায় সংশোধন করা হত) তবে এটি কেবল এই ধরণের আরও যুক্তি- ক্ষতিকারক শেননিগানগুলিকে মঞ্জুরি দেয় । উপরের উদাহরণে, প্রয়োগটিতে কেবলমাত্র স্বাক্ষরের দ্বারা নির্ধারিত প্রত্যাশা লঙ্ঘন করতে পারে যদি তালিকাটিতে কমপক্ষে একটি উপাদান থাকে; তবে যদি সংশোধন Tকরা হয় তবে তালিকাটি খালি থাকলেও এটি এটি করতে পারে। সংশোধিত প্রকারগুলি কোড সম্পর্কে আমাদের বোঝার বাধা দেওয়ার জন্য (ইতিমধ্যে অনেকগুলি) সম্ভাবনা বাড়িয়ে তুলবে।
প্রকারের ক্ষয়টি ভাষাটিকে "শক্তিশালী" কম করে। তবে "শক্তি" এর কিছু রূপগুলি আসলে ক্ষতিকারক।
instanceofদেওয়ার মতো জিনিসগুলি কী ধরণের ভিত্তিতে কী কোড করে তা নিয়ে আমাদের যুক্তি করার ক্ষমতাকে বাধা দেয়। যদি জাভা টাইপ যুক্তিগুলি সংশোধন করে তবে এটি কেবল এই সমস্যাটিকে আরও খারাপ করে দেবে। রানটাইমের সময় প্রকারগুলি মুছে ফেলার ফলে টাইপ সিস্টেমটিকে আরও কার্যকর করা যায়।
এটি সরাসরি উত্তর নয় (ওপি "কী কী সুবিধা" জিজ্ঞাসা করেছে, আমি "কী কী তা" জবাব দিচ্ছি)
সি # টাইপ সিস্টেমের সাথে তুলনা করে, জাভা টাইপ মুছে ফেলা দুটি রাইসের জন্য আসল ব্যথা
সি # তে আপনি উভয় IEnumerable<T1>এবং IEnumerable<T2>নিরাপদে বাস্তবায়ন করতে পারেন , বিশেষত যদি দুই প্রকারটি সাধারণ পূর্বপুরুষকে ভাগ না করে (যেমন তাদের পূর্বপুরুষ হয় Object )।
ব্যবহারিক উদাহরণ: স্প্রিং ফ্রেমওয়ার্কে, আপনি ApplicationListener<? extends ApplicationEvent>একাধিকবার প্রয়োগ করতে পারবেন না । আপনার যদি ভিত্তি করে বিভিন্ন আচরণের Tপ্রয়োজন হয় তবে আপনাকে পরীক্ষা করতে হবেinstanceof
(এবং এটি করার জন্য আপনার ক্লাসের একটি রেফারেন্স প্রয়োজন)
যেমনটি অন্যরা মন্তব্য করেছেন, সমতুল্য new T()কাজটি কেবল প্রতিচ্ছবির মাধ্যমেই করা যেতে পারে, কেবল কোনও উদাহরণ ব্যবহার Class<T>করে কনস্ট্রাক্টরের প্রয়োজনীয় পরামিতিগুলি সম্পর্কে নিশ্চিত হয়ে। প্যারামিটারলেস কনস্ট্রাক্টরকে সীমাবদ্ধ রাখলেই new T() কেবল সি # আপনাকে অনুমতি দেয় T। যদি Tসেই সীমাবদ্ধতার সম্মান না করে তবে একটি সংকলন ত্রুটি উত্থাপিত হবে।
জাভাতে, আপনি প্রায়শই নীচের মতো দেখতে এমন পদ্ধতিগুলি লিখতে বাধ্য হবেন
public <T> T create(....params, Class<T> classOfT)
{
... whatever you do
... you will end up
T = classOfT.newInstance();
... or more advanced reflection
Constructor<T> parameterizedConstructorThatYouKnowAbout = classOfT.getConstructor(...,...);
}
উপরের কোডে ত্রুটিগুলি হ'ল:
ReflectiveOperationExceptionযায় তবে রানটাইম নিক্ষেপ করা হয়আমি যদি সি # এর লেখক ছিলাম, আমি সংকলন সময়ে যাচাই করা সহজ যে এক বা একাধিক কনস্ট্রাক্টর সীমাবদ্ধতাগুলি নির্দিষ্ট করার সক্ষমতাটি প্রবর্তন করতাম (যাতে আমি উদাহরণস্বরূপ string,stringপ্যারামগুলির সাথে কোনও নির্মাণকারী প্রয়োজন )। তবে শেষটি জল্পনা
অতিরিক্ত উত্তর অন্য কোনও উত্তর বিবেচনা করেছে বলে মনে হয় না: রান-টাইম টাইপিংয়ের সাথে যদি আপনার সত্যিই জেনেরিকের প্রয়োজন হয় তবে আপনি নিজে এটিকে প্রয়োগ করতে পারেন :
public class GenericClass<T>
{
private Class<T> targetClass;
public GenericClass(Class<T> targetClass)
{
this.targetClass = targetClass;
}
এই শ্রেণিটি তখন জাভাটি ইরেজার ব্যবহার না করে ডিফল্টরূপে অর্জনযোগ্য সমস্ত জিনিস করতে সক্ষম হয়: এটি নতুন Tগুলি বরাদ্দ করতে পারে (ধরে নেওয়া যায় Tএমন কোনও কনস্ট্রাক্টর রয়েছে যা ব্যবহারের প্রত্যাশার সাথে মেলে) বা Tএটির অ্যারেগুলি , এটি করতে পারে গতিশীলভাবে রান সময় পরীক্ষা যদি একটি নির্দিষ্ট বস্তু হয়T এবং তার উপর নির্ভর করে আচরণ পরিবর্তন করে, ইত্যাদি।
উদাহরণ স্বরূপ:
public T newT () {
try {
return targetClass.newInstance();
} catch(/* I forget which exceptions can be thrown here */) { ... }
}
private T value;
/** @throws ClassCastException if object is not a T */
public void setValueFromObject (Object object) {
value = targetClass.cast(object);
}
}
সি ++ এড়ানো - কোড ব্লোটের মতো কারণ একই কোডটি একাধিক ধরণের জন্য ব্যবহৃত হয়; তবে টাইপ ইরেজারে ভার্চুয়াল প্রেরণের প্রয়োজন রয়েছে যেখানে সি ++ - কোড-ব্লোট অ্যাপ্রোচ ভার্চুয়াল প্রেরণ জেনেরিকগুলি করতে পারে
বেশিরভাগ উত্তর প্রকৃত প্রযুক্তিগত বিবরণের চেয়ে প্রোগ্রামিং দর্শনের বিষয়ে বেশি উদ্বিগ্ন।
যদিও এই প্রশ্নটি 5 বছরেরও বেশি পুরানো, তবুও প্রশ্নটি স্থির থাকে: প্রযুক্তিগত দৃষ্টিকোণ থেকে টাইপ মোছা ইচ্ছে করে কেন? শেষ পর্যন্ত, উত্তরগুলি বরং সহজ (উচ্চতর স্তরে): https://en.wikedia.org/wiki/Type_erasure
রানটাইমের সময় সি ++ টেম্পলেটগুলির অস্তিত্ব নেই। সংকলক প্রতিটি অনুরোধের জন্য একটি সম্পূর্ণরূপে অনুকূলিত সংস্করণ প্রেরণ করে যার অর্থ কার্যকরকরণ প্রকার তথ্যের উপর নির্ভর করে না। কিন্তু কীভাবে একটি জেআইটি একই ফাংশনের বিভিন্ন সংস্করণ নিয়ে কাজ করে? শুধু একটি ফাংশন করা কি ভাল হবে না? এটি চাইবে না যে জেআইটি এর সমস্ত বিভিন্ন সংস্করণ অনুকূলিত করবে। ঠিক আছে, তবে টাইপ সুরক্ষা সম্পর্কে কি? অনুমান যে উইন্ডো বাইরে যেতে হবে।
তবে এক সেকেন্ড অপেক্ষা করুন: নেট কীভাবে এটি করে? প্রতিবিম্ব! এইভাবে তাদের কেবল একটি ফাংশন অনুকূল করতে হবে এবং রানটাইম টাইপের তথ্যও পেতে হবে। আর এ কারণেই। নেট জেনেরিকগুলি ধীর হয়ে উঠত (যদিও তারা আরও উন্নত হয়েছে)। আমি তর্ক করছি না যে এটি সুবিধাজনক নয়! তবে এটি ব্যয়বহুল এবং এটি যখন একেবারে প্রয়োজনীয় না হয় তখন ব্যবহার করা উচিত নয় (এটি গতিশীল টাইপযুক্ত ভাষাগুলিতে ব্যয়বহুল বলে মনে করা হয় না কারণ সংকলক / দোভাষা যেভাবেই প্রতিবিম্বের উপর নির্ভর করে)।
টাইপ ইরেজর সাথে জেনেরিক প্রোগ্রামিং শূন্য ওভারহেডের কাছাকাছি (কিছু রানটাইম চেক / ক্যাসট এখনও প্রয়োজনীয়): https://docs.oracle.com/javase/tutorial/java/generics/erasure.html