জাভা: সংগ্রহগুলি কেন তুলনামূলক গ্রহণ করে তবে (অনুমানমূলক) হাশর এবং নিরক্ষীয় স্থানটিকে কেন গ্রহণ করে না?

Question

আপনি যখন কোনও ইন্টারফেসের বিভিন্ন বাস্তবায়ন করেন তখন এই সমস্যাটি সর্বাধিক স্পষ্ট হয় এবং নির্দিষ্ট সংগ্রহের উদ্দেশ্যে আপনি কেবলমাত্র অবজেক্টগুলির ইন্টারফেস-স্তরের দৃষ্টিভঙ্গিই যত্নবান হন। উদাহরণস্বরূপ, ধরুন আপনার এইরকম একটি ইন্টারফেস ছিল:

public interface Person {
    int getId();
}

ক্লাস বাস্তবায়ন hashcode()এবং প্রয়োগের স্বাভাবিক পদ্ধতিতে পদ্ধতিতে equals()এই জাতীয় কোড থাকবে equals:

if (getClass() != other.getClass()) {
    return false;
}

যখন তোমাদের মধ্যে বাস্তবায়নের মিশ্রিত করা এই সমস্যার কারণ Personএকটি HashMap। যদি HashMapকেবলমাত্র ইন্টারফেস-স্তরের দৃষ্টিভঙ্গির বিষয়ে চিন্তা করে Personতবে তা কেবল তাদের বাস্তবায়নকারী ক্লাসে পৃথক নকলের সাথে শেষ হতে পারে।

আপনি equals()সমস্ত বাস্তবায়নের জন্য একই উদার পদ্ধতি ব্যবহার করে এই কেসটিকে কাজ করতে পারেন তবে তারপরে আপনি অন্য equals()কোনও প্রসঙ্গে ভুল কাজটি করার ঝুঁকি চালান (যেমন Personসংস্করণ সংখ্যার সাথে ডাটাবেস রেকর্ড দ্বারা সমর্থিত দুটি গুলি তুলনা )।

আমার অন্তর্নিহিততা আমাকে বলেছে যে প্রতি ক্লাসের পরিবর্তে সংগ্রহের জন্য সাম্যতা সংজ্ঞায়িত করা উচিত। ক্রমের উপর নির্ভরশীল সংগ্রহগুলি ব্যবহার করার সময়, আপনি Comparatorপ্রতিটি প্রসঙ্গে সঠিক ক্রম বাছাই করতে একটি কাস্টম ব্যবহার করতে পারেন । হ্যাশ-ভিত্তিক সংগ্রহের জন্য কোনও অ্যানালগ নেই। কেন?

কেবল স্পষ্ট করে বলার জন্য, এই প্রশ্নটি " ইন্টারফেসে .compareTo () কেন, জাভাতে কোয়ালিটি () ক্লাসে থাকে? " থেকে পৃথক কারণ এটি সংগ্রহগুলি বাস্তবায়নের সাথে সম্পর্কিত। compareTo()এবং equals()/ hashcode()উভয়ই সংগ্রহ ব্যবহার করার সময় সর্বজনীনতার সমস্যায় ভুগছেন: আপনি বিভিন্ন সংগ্রহের জন্য আলাদা তুলনা ফাংশন বেছে নিতে পারবেন না। সুতরাং এই প্রশ্নের উদ্দেশ্যগুলির জন্য, কোনও জিনিসের উত্তরাধিকারের শ্রেণিবিন্যাস কোনও বিষয় নয়; তুলনামূলক ফাংশনটি প্রতি-বস্তু বা প্রতি-সংকলনের সংজ্ঞায়িত কিনা তা গুরুত্বপূর্ণ।

Comments

Personপ্রত্যাশিত equalsএবং hashCodeআচরণ বাস্তবায়নের জন্য আপনি সর্বদা মোড়কের জিনিসগুলি প্রবর্তন করতে পারেন । আপনি তখন একটি ছিল HashMap<PersonWrapper, V>। এটি একটি উদাহরণ যেখানে খাঁটি-ওওপি পদ্ধতির মার্জিত নয়: কোনও বস্তুর প্রতিটি ক্রিয়াকলাপই সেই বস্তুর একটি পদ্ধতি হিসাবে বোধ করে না। জাভার পুরো Objectটাইপ বিভিন্ন দায়িত্ব সংমিশ্রণ হয় - শুধুমাত্র getClass, finalizeএবং toStringপদ্ধতি আজকের সর্বোত্তম কার্যাভ্যাস দ্বারা দূরবর্তী সমর্থনীয় বলে মনে হচ্ছে।

— আমন

1) সি # তে আপনি IEqualityComparer<T>একটি হ্যাশ ভিত্তিক সংগ্রহকে পাস করতে পারেন । আপনি যদি একটি নির্দিষ্ট না করে থাকেন তবে এটি Object.Equalsএবং এর উপর ভিত্তি করে একটি ডিফল্ট বাস্তবায়ন ব্যবহার করে Object.GetHashCode()। 2) Equalsকোনও পরিবর্তনীয় রেফারেন্স ধরণের আইএমও ওভাররাইড করা খুব কমই ভাল ধারণা। এইভাবে ডিফল্ট সাম্যতা বেশ কঠোর, তবে যখন আপনি একটি কাস্টমের মাধ্যমে প্রয়োজন তখন আপনি আরও স্বচ্ছন্দ সাম্যের নিয়মটি ব্যবহার করতে পারেন IEqualityComparer<T>।

— কোডসইনচওস

সম্পর্কিত মেটা প্রশ্ন: এই প্রশ্নগুলি একে অপরের নকল?

Answer 1

এই নকশাটি কখনও কখনও "ইউনিভার্সাল ইক্যুয়ালিটি" নামে পরিচিত, এটি বিশ্বাস যে দুটি জিনিস সমান হয় বা না সর্বজনীন সম্পত্তি।

আরও বড় কথা, সাম্যতা দুটি বস্তুর সম্পত্তি , কিন্তু ওওতে আপনি সর্বদা একটি একক বস্তুতে একটি পদ্ধতি কল করেন এবং সেই অবজেক্টটি কীভাবে সেই পদ্ধতি কলটি পরিচালনা করবেন তা সম্পূর্ণ সিদ্ধান্ত নিতে পারে। সুতরাং, জাভা এর মতো নকশায় যেখানে সমতা দুটি বস্তুর মধ্যে একটির সম্পত্তি হিসাবে তুলনা করা হচ্ছে, সেখানে সাম্যতার ( a == b⇔ b == a) মতো সাম্যের কিছু প্রাথমিক বৈশিষ্ট্যগুলির গ্যারান্টি দেওয়া এমনকি সম্ভব নয় , কারণ প্রথম ক্ষেত্রে, পদ্ধতিটি আহ্বান জানানো হচ্ছে aএবং দ্বিতীয় ক্ষেত্রে এটি আহ্বান করা হচ্ছে bএবং ওও এর মূল নীতিগুলির কারণে এটি এককভাবে aসিদ্ধান্ত নেওয়া (প্রথম ক্ষেত্রে) বাbনিজের সিদ্ধান্তটিকে অন্যের সাথে সমান বলে বিবেচনা করে কিনা (দ্বিতীয় ক্ষেত্রে) এর সিদ্ধান্ত। প্রতিসাম্য অর্জনের একমাত্র উপায় হ'ল দুটি বস্তুকে সহযোগিতা করা, তবে তারা যদি না করে ... শক্ত ভাগ্য।

একটি সমাধান হ'ল সমতাটি একটি বস্তুর সম্পত্তি নয়, তবে দুটি বস্তুর সম্পত্তি বা তৃতীয় বস্তুর সম্পত্তি of এই পরবর্তী বিকল্পটি সর্বজনীন সাম্যতার সমস্যাও সমাধান করে, কারণ আপনি যদি সাম্যকে তৃতীয় "প্রসঙ্গ" বস্তুর সম্পত্তি হিসাবে পরিণত করেন, তবে আপনি EqualityComparerবিভিন্ন প্রসঙ্গের জন্য আলাদা আলাদা বস্তু থাকার কথা কল্পনা করতে পারেন ।

এই হল নকশা উদাহরণস্বরূপ, Haskell, জন্য নির্বাচিত, সঙ্গে Eqtypeclass। এটি কয়েকটি তৃতীয় পক্ষের স্কালা লাইব্রেরি দ্বারা নির্বাচিত নকশা (উদাহরণস্বরূপ স্কালাজ), তবে স্কালা কোর বা মানক গ্রন্থাগার নয়, যা অন্তর্নিহিত হোস্ট প্ল্যাটফর্মের সাথে সামঞ্জস্যের জন্য সর্বজনীন সাম্যতা ব্যবহার করে।

এটি আকর্ষণীয়ভাবে জাভা Comparable/ Comparatorইন্টারফেসগুলির সাথে বেছে নেওয়া নকশা । জাভাটির ডিজাইনারগণ সমস্যাটি সম্পর্কে স্পষ্টভাবে ওয়াকিবহাল ছিলেন, তবে কোনও কারণে এটি কেবল অর্ডার দেওয়ার জন্য সমাধান করেছিলেন, তবে সমতার জন্য নয় (বা হ্যাশিং)।

সুতরাং, প্রশ্ন হিসাবে

কেন একটি Comparatorইন্টারফেস কিন্তু না Hasherএবং Equator?

উত্তরটি "আমি জানি না"। স্পষ্টতই, জাভা ডিজাইনাররা সমস্যা সম্পর্কে সচেতন ছিলেন, এর অস্তিত্বের প্রমাণ হিসাবে Comparator, তবে তারা অবশ্যই এটিকে সাম্যতা এবং হ্যাশিংয়ের জন্য সমস্যা মনে করেনি। অন্যান্য ভাষা এবং গ্রন্থাগারগুলি বিভিন্ন পছন্দ করে।

Comments

+1, তবে মনে রাখবেন যে ওও ভাষা রয়েছে যেখানে একাধিক প্রেরণের উপস্থিতি রয়েছে (স্মলটালক, কমন লিস্প)। সুতরাং নিম্নলিখিত বাক্যটিতে সর্বদা খুব শক্তিশালী: "ওওতে, আপনি সর্বদা একটি একক বস্তুতে কোনও পদ্ধতিতে কল করেন"।

— coredump

আমি যে উদ্ধৃতিটি সন্ধান করছিলাম তা পেয়েছি; JLS 1.0 অনুযায়ী, The methods equals and hashCode are declared for the benefit of hashtables such as java.util.Hashtableঅর্থাৎ উভয় equalsএবং hashCodeযেমন চালু হয়েছে Objectজাভা দ্বারা পদ্ধতি devs একমাত্র অনুরোধে জন্য Hashtable- সেখানে ইউই অথবা বৈশিষ্ট কিছু silimar যে কোন জায়গায় কোন ধারণা আছে, এবং উদ্ধৃতি আমার জন্য স্পষ্ট যথেষ্ট; যদি না Hashtable, equalsসম্ভবত মতো ইন্টারফেসে চলেছি হবে Comparable। যেমন, আমি পূর্বে আপনার উত্তরটিকে সঠিক বলে বিশ্বাস করি, এখন আমি এটিকে অসম্পূর্ণ বিবেচনা করি।

— ভ্যাক্সকুইস

@ জার্গডব্লিউমিতাগ এটি একটি টাইপ, আইএফটিএফওয়াই ছিল। বিটিডাব্লু, কথা বলছি clone- এটি মূলত একটি অপারেটর ছিল , কোনও পদ্ধতি নয় (ওক ভাষা নির্দিষ্টকরণ দেখুন), উদ্ধৃতি: The unary operator clone is applied to an object. (...) The clone operator is normally used inside new to clone the prototype of some class, before applying the initializers (constructors)- তিনটি কীওয়ার্ডের মতো অপারেটর ছিলেন instanceof new clone(বিভাগ 8.1, অপারেটর)। আমি ধরে নিয়েছি clone/ Cloneableমেসের আসল (historicতিহাসিক) কারণ - Cloneableএটি কেবল পরে আবিষ্কার cloneছিল এবং বিদ্যমান কোডটি এটির সাথে পুনঃনির্মাণ ছিল।

— ভ্যাক্সকুইস

"এটি হ্যাস্কেলের জন্য বেছে নেওয়া নকশা, উদাহরণস্বরূপ, একিউ টাইপক্লাসের সাথে" এটি এক ধরণের সত্য, তবে এটি লক্ষণীয় যে, হাস্কেল স্পষ্টভাবে সামনে বলেছে যে বিভিন্ন ধরণের দুটি বস্তু কখনই সমান হয় না যখন জাভার দৃষ্টিভঙ্গি হয় না। সমতা অপারেশনটি এই ধরণের অংশ , (সুতরাং "টাইপক্লাস") তৃতীয় প্রসঙ্গ মানটির অংশ নয়।

— জ্যাক

Answer 2

আসল উত্তর

কেন একটি Comparatorইন্টারফেস কিন্তু না Hasherএবং Equator?

হ'ল, জোশ ব্লচের সৌজন্যে :

আসল জাভা এপিআইগুলি একটি ক্লোজড মার্কেট উইন্ডোটি পূরণ করতে একটি শক্ত সময়সীমার অধীনে খুব দ্রুত সম্পন্ন করা হয়েছিল। আসল জাভা দলটি অবিশ্বাস্য কাজ করেছে, তবে এপিআইয়ের সমস্তই নিখুঁত নয়।

সমস্যা অন্যান্য অনুরূপ বিষয়গুলি, যেমন মত জাভা ইতিহাসে একমাত্র মিথ্যা, .clone()বনাম Cloneable।

TL; ড

এটি মূলত historicalতিহাসিক কারণে; বর্তমান আচরণ / বিমূর্ততা জেডিকে ১.০ এ প্রবর্তিত হয়েছিল এবং এটি পরে ঠিক করা হয়নি কারণ পিছিয়ে কোডের সামঞ্জস্যতা বজায় রেখে এটি করা কার্যত অসম্ভব ছিল।

---

প্রথমে আসুন কয়েকটি সুপরিচিত জাভা তথ্য সংকলন করা যাক:

1. জাভা, প্রথম থেকে আজ অবধি গর্বের সাথে পিছনের দিকে সামঞ্জস্যপূর্ণ, লেগ্যাসি এপিআইগুলি এখনও নতুন সংস্করণগুলিতে সমর্থিত হওয়া প্রয়োজন,
2. যেমন, জেডিকে ১.০ এর সাথে প্রবর্তিত প্রায় প্রতিটি এবং প্রতিটি ভাষা নির্মাণ আজকাল বেঁচে ছিল,
3. Hashtable, .hashCode()এবং জেডিকে.equals() ১.০ এ প্রয়োগ করা হয়েছিল ( হ্যাশটেবল )
4. Comparable/ Comparatorজেডিকে ১.২ ( তুলনীয় ) তে প্রবর্তিত হয়েছিল ,

এখন, এটি অনুসরণ:

5. কার্যত অসম্ভব & রেট্রোফিট করার অজ্ঞান .hashCode()ও .equals()স্বতন্ত্র ইন্টারফেসগুলি যখন এখনও মানুষ পর পিছন সামঞ্জস্য বজায় রাখার উপলব্ধি তাদের superobject নির্বাণ চেয়ে ভাল বিমূর্ত আছে, কারণ যেমন প্রতিটি এক 1.2 দ্বারা জাভা প্রোগ্রামার জানতেন যে যে Objectতাদের আছে, এবং তারা ছিল কম্পাইল কোড (জেভিএম) সামঞ্জস্যতাও শারীরিকভাবে সেখানে থাকার জন্য - এবং প্রতিটি Objectসাবক্লাসে একটি বাস্তব স্পেস ইন্টারফেস যুক্ত করা যা তাদের বাস্তবায়িত করে এই জগাখিচুড়ি সমান (sic!) Clonableএকের সমান করে দেবে ( ব্লচ আলোচনা করে কেন ক্লোনযোগ্য সফল হয়, উদাহরণস্বরূপ EJ 2 য় আলোচিত) এবং এসও সহ আরও অনেক স্থান),
6. ভবিষ্যতের প্রজন্মের ডাব্লুটিএফ-এর একটি অবিচ্ছিন্ন উত্স পাওয়ার জন্য তারা কেবল তাদের সেখানে রেখে গেছে।

এখন, আপনি জিজ্ঞাসা করতে পারেন " Hashtableএই সমস্ত কি আছে"?

উত্তরটি হ'ল: hashCode()/equals() 1995 এবং ১৯৯৯ / ১৯৯6 সালে মূল জাভা বিকাশকারীদের পক্ষে ভাষা চুক্তি এবং তেমন ভাল না ভাষা দক্ষতার দক্ষতা।

জাভা 1.0 ভাষা প্রতিবেদনের উদ্ধৃতি , তারিখ 1996 - 4.3.2 ক্লাস Object, পৃষ্ঠা 45:

পদ্ধতিগুলি equalsএবং হ্যাশ টেবিলের hashCodeসুবিধার জন্য যেমন ঘোষণা করা হয় java.util.Hashtable(21.7.7)। সমান পদ্ধতিটি অবজেক্টের সাম্যের ধারণাটি সংজ্ঞায়িত করে, যা মানের উপর ভিত্তি করে, রেফারেন্স, তুলনা করে না।

(নোট ঠিক এই বিবৃতি হয়েছে পরিবর্তিত : পরে সংস্করণে বলতে উদ্ধৃতি The method hashCode is very useful, together with the method equals, in hashtables such as java.util.HashMap., এটা অসম্ভব সরাসরি করতে উপার্জন Hashtable- hashCode- equalsঐতিহাসিক JLS পড়া ছাড়া সংযোগ!)

জাভা দল সিদ্ধান্ত নিয়েছে যে তারা একটি ভাল অভিধান-স্টাইলের সংগ্রহ চায়, এবং তারা তৈরি করেছে Hashtable(এখনও অবধি ভাল ধারণা) তবে তারা চেয়েছিল যে প্রোগ্রামার এটি যতটা সম্ভব কম কোড / শেখার বক্ররেখ ব্যবহার করতে সক্ষম হবে (ওফ! সমস্যা আগত!) - এবং, যেহেতু এখনো [এটা JDK 1.0 সব পরে] কোনো জেনেরিক্স হয়েছিলেন যে অর্থ হবে যে হয় যে Object পুরা Hashtableস্পষ্টভাবে কিছু ইন্টারফেস বাস্তবায়ন করতে হবে (এবং ইন্টারফেস তখন শুধু তাদের শুরু মধ্যে আছেন তাই ... কোনও Comparableএমনকি এখনো!) , এই একটি প্রতিবন্ধক উপার্জন অনেকের জন্য এটি ব্যবহার করতে - বা Objectকরতে হবে পরোক্ষভাবে কিছু হ্যাশ পদ্ধতি বাস্তবায়ন।

স্পষ্টতই, তারা উপরোক্ত কারণগুলির জন্য সমাধান 2 নিয়ে গেল। হ্যাঁ, এখন আমরা জানি তারা ভুল ছিল। _{... হ্যান্ডসাইটে স্মার্ট হওয়া সহজ। মৃদুহাস্য}

এখন, hashCode() প্রয়োজন যে প্রতিটি বস্তুর এটির একটি পৃথক equals()পদ্ধতি থাকতে হবে - সুতরাং এটি স্পষ্টভাবে স্পষ্ট equals()ছিল যে এটিও রাখা উচিত Object।

যেহেতু ডিফল্ট বৈধ সেই পদ্ধতি বাস্তবায়নের a& b Object(উপার্জন গুলি মূলত অপ্রয়োজনীয় হচ্ছে বেহুদা হয় a.equals(b) সমান করতে a==bএবং a.hashCode() == b.hashCode() মোটামুটিভাবে সমান করতে a==b, এছাড়াও , যদি না hashCodeএবং / অথবা equalsওভাররাইড করা হয়, অথবা আপনি জিসি কয়েক হাজার Objectআপনার আবেদনের জীবনচক্র সময় গুলি ¹ ) , এটি নিরাপদ যে এগুলিকে মূলত ব্যাকআপ ব্যবস্থা এবং ব্যবহারের সুবিধার জন্য সরবরাহ করা হয়েছিল তা বলা নিরাপদ। ঠিক একইভাবে আমরা সুপরিচিত সত্যের কাছে পৌঁছে যাই যে উভয়কেই সর্বদা ওভাররাইড করে .equals()এবং .hashCode()আপনি যদি বস্তুগুলির সাথে তুলনা করতে বা হ্যাশ-স্টোর করার চেষ্টা করেন। অন্যটি ছাড়াই কেবল একটির ওভাররাইড করা আপনার কোডটি স্ক্রু করার একটি ভাল উপায় (দুষ্টু ফলাফলের তুলনায় বা অত্যধিক উচ্চ বালতির সংঘর্ষের মানগুলি দ্বারা) - এবং এটির চারপাশে আপনার মাথা পাওয়াটি ধ্রুবক বিভ্রান্তির কারণ এবং নতুনদের জন্য ত্রুটি (অনুসন্ধানের জন্য এসও অনুসন্ধান করুন) এটি নিজের জন্য) এবং আরও পাকা ব্যক্তিদের কাছে ধ্রুবক উপদ্রব।

এছাড়াও, মনে রাখবেন যে যদিও ভাল উপায় বিট সমান & একটি হ্যাশকোড সঙ্গে সি # পুলিশ এরিক Lippert নিজে যে তারা C # এর প্রায় একই ভুল করেনি সূর্য জাভা বছর করেছিল সি # 'গুলি শুরু করার আগে :

তবে কেন এমন হওয়া উচিত যে প্রতিটি বস্তুর একটি হ্যাশ টেবিলের মধ্যে প্রবেশের জন্য নিজেকে হ্যাশ করতে সক্ষম হওয়া উচিত? প্রতিটি অবজেক্টটি সক্ষম হতে সক্ষম হওয়া একটি বিজোড় জিনিসের মতো মনে হয়। আমি মনে করি আমরা যদি আজ থেকে স্ক্র্যাচ থেকে টাইপ সিস্টেমটিকে নতুনভাবে ডিজাইন করছিলাম, হ্যাশিং অন্যরকমভাবে করা হতে পারে, সম্ভবত কোনও IHashableইন্টারফেস দিয়ে। কিন্তু যখন সিএলআর টাইপ সিস্টেমটি তৈরি করা হয়েছিল তখন কোনও জেনেরিক প্রকার ছিল না এবং তাই কোনও সাধারণ-উদ্দেশ্য হ্যাশ টেবিলটি কোনও বস্তু সঞ্চয় করতে সক্ষম হওয়ার প্রয়োজন ছিল।

¹ অবশ্যই, Object#hashCodeএখনও সংঘর্ষ করতে পারে, তবে এটি করতে কিছুটা প্রচেষ্টা দরকার, দেখুন: http://bugs.java.com/bugdatedia/view_bug.do?bug_id=6809470 এবং বিশদ সম্পর্কিত লিঙ্কযুক্ত বাগ রিপোর্ট; /programming/1381060/hashcode-uniqueness/1381114#1381114 এই বিষয়টিকে আরও গভীরতার সাথে কভার করে।

Comments

যদিও এটি কেবল জাভা নয়। এর সমসাময়িকদের মধ্যে অনেকগুলি (রুবি, পাইথন,…) এবং পূর্বসূরীদের (স্মলটাল্ক,…) এবং এর উত্তরসূরিদের কিছুগুলির রয়েছে ইউনিভার্সাল ইক্যুয়ালিটি এবং ইউনিভার্সাল হ্যাশাবিলিটি (এটি কি একটি শব্দ?)।

— Jörg W Mittag

@ জার্গডব্লিউমিত্যাগ প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার.কম / সেকশনস / ২২৩১৯৪/২ দেখুন - জাভাতে "ইউই" সম্পর্কে আমার একমত হতে হবে না; ইউই historতিহাসিকভাবে কখনও Objectডিজাইনের ক্ষেত্রে সত্যিকারের উদ্বেগ ছিল না ; হ্যাশাবিলিটি ছিল।

— ভ্যাক্সকুইস

@ ভ্যাক্সকুইস আমি এটিতে বীণা বসাতে চাই না, তবে আমার পূর্ববর্তী মন্তব্যটি দেখায় যে দুটি একই সাথে পৌঁছনীয় অবজেক্টগুলিতে একই (ডিফল্ট) হ্যাশ কোড থাকতে পারে।

— মনিকা পুনরায়

@ ভ্যাক্স্কুইস ঠিক আছে আমি এটি কিনেছি। আমার উদ্বেগ হ'ল যে কেউ এই শিক্ষা গ্রহণ করছে তারা এটি দেখতে পাবে এবং তারা সমানগুলির পরিবর্তে সিস্টেম হ্যাশকোড ব্যবহার করে চালাক বলে মনে করবে তারা যদি এটি করে থাকে তবে বিরল সময় ব্যতীত এটি সম্ভবত যথেষ্ট কাজ করবে এবং সেখানে হবে সমস্যাটি বিশ্বস্তভাবে পুনরুত্পাদন করার কোনও উপায় নয়।

— জিমি জেমস

এটি গ্রহণযোগ্য উত্তর হওয়া উচিত, যেহেতু গৃহীত উত্তরের উত্তরটি "আমি জানি না"

— ফিনিক্স