নাল যদি খারাপ হয় তবে আধুনিক ভাষা কেন এটি প্রয়োগ করে? [বন্ধ]

82

আমি নিশ্চিত জাভা বা সি # এর মতো ভাষার ডিজাইনাররা নাল রেফারেন্সের অস্তিত্ব সম্পর্কিত সমস্যাগুলি জানত (দেখুন নাল রেফারেন্সগুলি কি আসলেই খারাপ জিনিস? )। এছাড়াও একটি বিকল্প প্রকার বাস্তবায়ন নাল রেফারেন্সের চেয়ে অনেক বেশি জটিল নয়।

কেন তারা যেভাবেই এটি অন্তর্ভুক্ত করার সিদ্ধান্ত নিয়েছে? আমি নিশ্চিত নাল রেফারেন্সের অভাব ভাষা নির্মাতা এবং ব্যবহারকারী উভয়ই উন্নত মানের কোড (বিশেষত আরও ভাল গ্রন্থাগার নকশা) উত্সাহিত করবে।

এটি কি কেবল রক্ষণশীলতার কারণে - "অন্যান্য ভাষাগুলিরও আছে, আমাদেরও তা থাকতে হবে ..."?

language-design  null 
— mrpyo
সূত্র
99
নাল দুর্দান্ত। আমি এটি ভালবাসি এবং প্রতিদিন এটি ব্যবহার করি।
— পিটার বি
17
@ পিটারবি কিন্তু আপনি কি এটি সংখ্যাগরিষ্ঠ রেফারেন্সের জন্য ব্যবহার করেন, বা আপনি চান যে বেশিরভাগ রেফারেন্স বাতিল হয়ে যাবে না? যুক্তিটি এমন নয় যে অযৌক্তিক ডেটা থাকা উচিত নয়, কেবল এটি সুস্পষ্ট এবং অপ্ট-ইন করা উচিত।
11
@ পিটারবি কিন্তু যখন সংখ্যাগরিষ্ঠদের অযোগ্য হওয়া উচিত নয়, তখন ডিফল্টের চেয়ে নাল-সামর্থ্যকে ব্যতিক্রম করার অর্থ কী হবে না? নোট করুন যে বিকল্প বিকল্পগুলির স্বাভাবিক নকশাটি অনুপস্থিতি এবং আনপ্যাকিংয়ের জন্য সুস্পষ্ট চেকিংয়ের জন্য বাধ্য করা হয়, তবে একটির মধ্যে সুপরিচিত জাভা / সি # / ... শব্দার্থবিজ্ঞানগুলি অপ্ট-ইন বাতিলযোগ্য রেফারেন্সের জন্য থাকতে পারে (ব্যবহারযোগ্য যেমন নমনীয় নয়, ফুটিয়ে তোলা হবে) if নাল)। এটি কমপক্ষে কিছু ত্রুটিগুলি প্রতিরোধ করবে এবং স্থির বিশ্লেষণ করবে যা নাল চেকগুলি হারিয়ে যাওয়ার বিষয়ে অভিযোগ করে যা আরও অনেক বেশি ব্যবহারিক।
20
ডাব্লুটিএফ আপনার সাথে আছে? সফ্টওয়্যার দ্বারা যে সমস্ত জিনিস ভুল করতে পারে এবং করতে পারে তার মধ্যে নালকে মূল্যহীন করার চেষ্টা করা কোনও সমস্যা নয়। এটি সর্বদা একটি এভি / সেগফল্ট উত্পন্ন করে এবং ঠিক হয়ে যায়। আপনি কি এই নিয়ে উদ্বিগ্ন হওয়ার মতো এত বাগের ঘাটতি রয়েছে? যদি তা হয় তবে আমার কাছে অতিরিক্ত পরিমাণে বাছাই রয়েছে এবং এগুলির কোনওটিই নাল রেফারেন্স / পয়েন্টারগুলির সাথে সমস্যা উদ্ভাবন করে না।
— মার্টিন জেমস
13
@ মার্টিনজেমস "এটি সর্বদা একটি এভি / সেগফল্ট উত্পন্ন করে এবং ঠিক হয়ে যায়" - না, না এটি তা করে না।
— স্পষ্টত

উত্তর:

97

দাবি অস্বীকার: যেহেতু আমি কোনও ভাষা ডিজাইনারকে ব্যক্তিগতভাবে জানি না, তাই আমি আপনাকে যে উত্তর দেব তা অনুমানমূলক হবে।

টনি হোয়ার থেকে নিজে:

আমি এটিকে আমার বিলিয়ন ডলারের ভুল বলছি। এটি 1965 সালে নাল রেফারেন্সের আবিষ্কার ছিল that সেই সময়ে, আমি কোনও অবজেক্ট ওরিয়েন্টেড ল্যাঙ্গুয়েজে (ALGOL ডাব্লু) রেফারেন্সের জন্য প্রথম বিস্তৃত টাইপ সিস্টেমটি ডিজাইন করছিলাম। আমার লক্ষ্যটি নিশ্চিত করা ছিল যে কম্পাইলার দ্বারা স্বয়ংক্রিয়ভাবে সঞ্চালিত চেক সহ সমস্ত উল্লেখের ব্যবহার একেবারেই নিরাপদ হওয়া উচিত। তবে নাল রেফারেন্স দেওয়ার প্রলোভনটি আমি প্রতিহত করতে পারিনি, কেবল কারণ এটি কার্যকর করা এত সহজ ছিল। এর ফলে অসংখ্য ত্রুটি, দুর্বলতা এবং সিস্টেম ক্র্যাশ হয়েছে, যা সম্ভবত চল্লিশ বছরে এক বিলিয়ন ডলার ব্যথা এবং ক্ষতির কারণ হয়ে দাঁড়িয়েছে।

জোর আমার।

স্বাভাবিকভাবেই এ সময়টি তার কাছে খারাপ ধারণা বলে মনে হয় নি। সম্ভবত এটি একই কারণে অংশে স্থায়ী হয়েছে - যদি কুইকোর্টের টুরিং অ্যাওয়ার্ড-বিজয়ী উদ্ভাবককে এটি ভাল ধারণা বলে মনে হয়, তবে অবাক হওয়ার মতো কিছু নেই যে এটি কেন খারাপ তা এখনও অনেকে বুঝতে পারেন না। এটি সম্ভবত অংশেও রয়েছে কারণ বিপণন ও বক্ররেখা উভয়ের কারণে নতুন ভাষার পক্ষে পুরানো ভাষার সাথে মিল থাকা সুবিধাজনক। বিন্দু ক্ষেত্রে:

"আমরা সি ++ প্রোগ্রামারদের পরে ছিলাম। আমরা তাদের বেশিরভাগটিকে প্রায় অর্ধেক পর্যন্ত লিস্পে টেনে আনতে সক্ষম হয়েছি।" -গুই স্টিল, জাভা স্পেসের সহ-লেখক

(সূত্র: http://www.paulgraham.com/icad.html )

এবং অবশ্যই, সি ++ টি বাতিল হয়ে গেছে কারণ সি নাল রয়েছে, এবং সি এর historicalতিহাসিক প্রভাবের মধ্যে যাওয়ার দরকার নেই। ছাপিয়ে জে ++, সি # ধরনের, যা জাভার Microsoft এর বাস্তবায়ন ছিল, এবং এটি, সি ++ ছাপিয়ে এর উইন্ডোজ উন্নয়নের জন্য পছন্দের ভাষা হিসেবে তাই এটি হয় এক থেকে এটা অর্জিত করেছি পারে।

সম্পাদনা এখানে হোয়ারের আরেকটি উক্তি বিবেচনাযোগ্য:

প্রোগ্রামিং ল্যাঙ্গুয়েজগুলি আগে যেমন ছিল তার চেয়ে অনেক বেশি জটিল: অবজেক্ট অরিয়েন্টেশন, উত্তরাধিকার এবং অন্যান্য বৈশিষ্ট্যগুলি এখনও একটি সুসংগত এবং বৈজ্ঞানিকভাবে সু-ভিত্তিক শৃঙ্খলা বা নির্ভুলতার তত্ত্বের দৃষ্টিকোণ থেকে বিবেচনা করা হচ্ছে না are । আমার আসল পোষ্টুলেট, যা আমি সারা জীবন একজন বিজ্ঞানী হিসাবে অনুসরণ করে চলেছি তা হ'ল যে কোনও একটি শালীন প্রোগ্রামিং ভাষার নকশাকে রূপান্তর করার মাধ্যম হিসাবে সঠিকতার মানদণ্ডটি ব্যবহার করে - যা তার ব্যবহারকারীদের জন্য ফাঁদ তৈরি করে না এবং এতে রয়েছে যা প্রোগ্রামের বিভিন্ন উপাদানগুলি তার স্পেসিফিকেশনের বিভিন্ন উপাদানগুলির সাথে পরিষ্কারভাবে মেলে, তাই আপনি এটি সম্পর্কে রচনাগতভাবে যুক্তি দিতে পারেন। [...] সংকলক সহ সরঞ্জামগুলি একটি সঠিক প্রোগ্রাম লেখার অর্থ কি কিছু তত্ত্বের ভিত্তিতে থাকতে হবে। ফিলিপ এল। ফ্রানা দ্বারা 17 জুলাই 2002, কেমব্রিজ, ইংল্যান্ডের মৌখিক ইতিহাস সাক্ষাত্কার; চার্লস ব্যাবেজ ইনস্টিটিউট, মিনেসোটা বিশ্ববিদ্যালয় [[ http://www.cbi.umn.edu/oh/display.phtml?id=343]

আবার, জোর আমার। সান / ওরাকল এবং মাইক্রোসফ্ট হল সংস্থাগুলি এবং যে কোনও সংস্থার নীচের অংশটি অর্থ হয় is তাদের থাকার nullউপকারিতা দূষিত হতে পারে বা এ বিষয়টি পুরোপুরি বিবেচনা করার জন্য তাদের খুব সময়সীমা থাকতে পারে। কোনও ভিন্ন ভাষার ভুলের উদাহরণ হিসাবে সম্ভবত ডেডলাইনের কারণে ঘটেছিল:

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

(সূত্র: http://www.artima.com/intv/bloch13.html )

— Doval
সূত্র
32
প্রিয় ডাউনভোটার: আমি কীভাবে আমার উত্তরকে উন্নত করতে পারি?
— ডোভাল
6
আপনি আসলে প্রশ্নের উত্তর দেননি; আপনি কেবল কিছু-বাস্তব-মতামত সম্পর্কে কিছু উক্তি এবং "ব্যয়" সম্পর্কে কিছু অতিরিক্ত হ্যান্ড-ওয়েভিং সরবরাহ করেছিলেন। (নাল যদি এক বিলিয়ন ডলারের ভুল হয় তবে এমএস এবং জাভা দ্বারা রক্ষা করা ডলারের প্রয়োগটি কি সেই debt
— ণ
29
@ ডগএম আপনি আমার কাছে কী প্রত্যাশা করবেন, বিগত ৫০ বছর ধরে প্রতিটি ভাষা ডিজাইনারকে ধরে ফেলুন এবং তাকে জিজ্ঞাসা করবেন কেন তিনি nullতাঁর ভাষায় প্রয়োগ করেছেন? কোনও ভাষা ডিজাইনার না এলে এই প্রশ্নের কোনও উত্তরই অনুমানযোগ্য হবে। আমি এরিক লিপার্ট ছাড়াও এই সাইটের প্রায়শই ঘন ঘন জানি না। শেষ অংশটি অসংখ্য কারণে একটি লাল রঙের হেরিং। এমএস এবং জাভার এপিআইয়ের উপরে লিখিত তৃতীয় পক্ষের কোডের পরিমাণ স্পষ্টতই এপিআইতে কোডের পরিমাণের চেয়ে বেশি। সুতরাং আপনার গ্রাহকরা চান null, আপনি তাদের দিতে null। আপনিও ধরুন যে তারা মেনে নিয়েছে nullতাদের জন্য অর্থ ব্যয় করা হচ্ছে।
— ডোভাল
3
যদি আপনি কেবল উত্তর দিতে পারেন তবে অনুমানযোগ্য, আপনার খোলার অনুচ্ছেদে স্পষ্টভাবে জানিয়ে দিন। (আপনি কীভাবে আপনার উত্তরটির উন্নতি করতে চেয়েছিলেন এবং আমি প্রতিক্রিয়া জানিয়েছিলাম Any যে কোনও প্যারেন্টিথিকাল কেবলমাত্র ভাষ্য যা আপনি অবহেলা করতে পারেন নির্দ্বিধায়; সর্বোপরি ইংরেজিতে
— এটিই প্রথম
7
এই উত্তর যুক্তিসঙ্গত; আমি খনিতে আরও কিছু বিবেচনা যুক্ত করেছি। আমি লক্ষ করি যে ICloneableএকইভাবে। নেট মধ্যে বিভক্ত হয়; দুর্ভাগ্যক্রমে এটি এমন এক জায়গা যেখানে জাভাটির ত্রুটিগুলি সময় মতো শিখেনি।
— এরিক লিপার্ট
121

আমি নিশ্চিত জাভা বা সি # এর মতো ভাষার ডিজাইনাররা নাল রেফারেন্সের অস্তিত্ব সম্পর্কিত সমস্যাগুলি জানত

অবশ্যই.

এছাড়াও একটি বিকল্প প্রকার বাস্তবায়ন নাল রেফারেন্সের চেয়ে অনেক বেশি জটিল নয়।

আমি পার্থক্য ভিক্ষা! সি # 2 এ যে নকশার বিবেচনাগুলি মূল্যহীন মান প্রকারে চলেছে সেগুলি জটিল, বিতর্কিত এবং কঠিন ছিল। তারা উভয় ভাষার ডিজাইন দল এবং রানটাইমের বহু মাস ধরে বিতর্ক, প্রোটোটাইপগুলি বাস্তবায়ন, এবং এগুলি গ্রহণ করেছিল এবং বাস্তবে নোলযোগ্য বক্সিংয়ের শব্দার্থবিজ্ঞান সি # 2.0 শিপিংয়ের খুব কাছাকাছি পরিবর্তিত হয়েছিল, যা অত্যন্ত বিতর্কিত ছিল।

কেন তারা যেভাবেই এটি অন্তর্ভুক্ত করার সিদ্ধান্ত নিয়েছে?

সমস্ত নকশা অনেক সূক্ষ্ম এবং গুরুতর বেমানান লক্ষ্যগুলির মধ্যে চয়ন করার প্রক্রিয়া; আমি বিবেচনা করা হবে যে কয়েকটি কারণের শুধুমাত্র একটি সংক্ষিপ্ত স্কেচ দিতে পারি:

  • ভাষার বৈশিষ্ট্যগুলির অরথোগোনালিটি সাধারণত একটি ভাল জিনিস হিসাবে বিবেচিত হয়। সি # এর অণনীয় মান প্রকার, অ-মূল্যহীন মান প্রকার এবং অযোগ্য রেফারেন্স প্রকার রয়েছে। নন-অযোগ্য রেফারেন্স ধরণের অস্তিত্ব নেই, যা টাইপ সিস্টেমটিকে অরথোগোনাল করে তোলে।

  • সি, সি ++ এবং জাভার বিদ্যমান ব্যবহারকারীদের পরিচিতি গুরুত্বপূর্ণ।

  • সিওএম এর সাথে সহজ আন্তঃঅযুক্তিযোগ্যতা গুরুত্বপূর্ণ।

  • অন্যান্য সমস্ত নেট ভাষার সাথে সহজেই আন্তঃক্রিয়াশীলতা গুরুত্বপূর্ণ।

  • ডাটাবেসগুলির সাথে সহজে আন্তঃঅযুক্তিযোগ্যতা গুরুত্বপূর্ণ।

  • শব্দার্থবিজ্ঞানের ধারাবাহিকতা গুরুত্বপূর্ণ; যদি আমাদের কাছে থিংকিঅফফ্রান্স নালির সমান উল্লেখ থাকে তবে এর অর্থ কি সর্বদা "ফ্রান্সের রাজা এখনই নেই", বা এর অর্থও "ফ্রান্সের রাজা অবশ্যই আছেন; আমি ঠিক জানি না এখনই কে?" বা এর অর্থ কি "ফ্রান্সে রাজা হওয়ার খুব ধারণা অযৌক্তিক, তাই এমনকি প্রশ্নও জিজ্ঞাসা করবেন না!" নাল এই সমস্ত কিছুর অর্থ এবং সি # তে আরও বেশি বোঝাতে পারে এবং এই সমস্ত ধারণাটি কার্যকর useful

  • পারফরম্যান্স ব্যয় গুরুত্বপূর্ণ।

  • স্থিতিশীল বিশ্লেষণের জন্য জবাবদিহি করা গুরুত্বপূর্ণ।

  • টাইপ সিস্টেমের ধারাবাহিকতা গুরুত্বপূর্ণ; আমরা করতে পারেন সবসময় জানি যে একটি অ-nullable রেফারেন্স কখনো অধীনে কোনো অবৈধ বলে পরিলক্ষিত পরিস্থিতিতে? রেফারেন্স প্রকারের একটি অ-অযোগ্য ক্ষেত্রের সাথে কোনও অবজেক্টের কনস্ট্রাক্টর সম্পর্কে কী বলা যায়? এই জাতীয় অবজেক্টের চূড়ান্তকরণের বিষয়ে কী, যেখানে রেফারেন্সটি পূরণ করার কথা বলে এমন কোডটি ব্যতিক্রম ছুঁড়েছিল বলে এই বিষয়টিকে চূড়ান্ত করা হয়েছে ? আপনার গ্যারান্টি সম্পর্কে মিথ্যা একটি টাইপ সিস্টেম বিপজ্জনক।

  • এবং শব্দার্থবিজ্ঞানের ধারাবাহিকতা সম্পর্কে কী? নাল মানগুলি ব্যবহারের সময় প্রচার করে তবে নাল উল্লেখগুলি ব্যবহার করার সময় ব্যতিক্রম ছুঁড়ে দেয়। এটি বেমানান; যে অসঙ্গতি কিছু সুবিধা দ্বারা ন্যায্য?

  • আমরা অন্যান্য বৈশিষ্ট্যগুলি ভঙ্গ না করে বৈশিষ্ট্যটি বাস্তবায়ন করতে পারি? ভবিষ্যতের অন্যান্য সম্ভাব্য বৈশিষ্ট্যগুলি বৈশিষ্ট্যটি কীভাবে আবদ্ধ হয়?

  • আপনি যে সেনাবাহিনী চান তার সাথে যুদ্ধ করতে যাবেন, আপনি চান না। মনে রাখবেন, সি # 1.0 এর জেনেরিকস ছিল না, সুতরাং Maybe<T>বিকল্প হিসাবে কথা বলা সম্পূর্ণ নন-স্টার্টার। রানটাইম টিম জেনেরিক যুক্ত করার সময় .NET কি দু'বছরের জন্য পিছলে থাকতে হবে?

  • টাইপ সিস্টেমের ধারাবাহিকতা সম্পর্কে কী? আপনি যে Nullable<T>কোনও মানের ধরণের জন্য বলতে পারেন - না, অপেক্ষা করুন, এটি মিথ্যা। আপনি বলতে পারবেন না Nullable<Nullable<T>>। আপনি সক্ষম হতে হবে? যদি তা হয় তবে এর কাঙ্ক্ষিত শব্দার্থক শব্দগুলি কী কী? পুরো বৈশিষ্ট্যটিকে কেবল এই বৈশিষ্ট্যটির জন্যই একটি বিশেষ কেস তৈরি করা কি উপযুক্ত?

ইত্যাদি। এই সিদ্ধান্তগুলি জটিল।

— এরিক লিপার্ট
সূত্র
12
+1 সমস্ত কিছুর জন্য তবে বিশেষত জেনারিকগুলি আনতে। এটি সহজেই ভুলে যাওয়া সহজ যে জাভা এবং সি # এর ইতিহাস উভয় ক্ষেত্রেই জেনেরিকের অস্তিত্ব ছিল না।
— ডোভাল
2
হতে পারে একটি বোবা প্রশ্ন (আমি কেবল একটি আইটি আন্ডারগ্রাজুয়েট) - তবে বিকল্প টাইপটি সিনট্যাক্স পর্যায়ে প্রয়োগ করা যায়নি (সিএলআর সম্পর্কে এটি সম্পর্কে কিছুই জানে না) ব্যবহারের আগে "হ্যাঁ-মান" পরীক্ষা প্রয়োজন that কোড? আমি বিশ্বাস করি বিকল্প সময়ে রানটাইমের সময় কোনও চেকের দরকার নেই।
— এমপিপিও 21
2
@ এমপিপিও: অবশ্যই, এটি সম্ভাব্য প্রয়োগের পছন্দ। অন্যান্য ডিজাইনের পছন্দগুলির কোনওটিই যায় না এবং বাস্তবায়ন পছন্দটির নিজস্ব অনেকগুলি মতামত রয়েছে।
— এরিক লিপার্ট
1
@ এমপিপিও আমি মনে করি "হেস-ভ্যালু" চেক জোর করে নেওয়া ভাল ধারণা নয়। তাত্ত্বিকভাবে এটি একটি খুব ভাল ধারণা, তবে বাস্তবে আইএমও এটি সমস্ত ধরণের খালি চেকগুলি আনবে কেবল সংকলককে সন্তুষ্ট করার জন্য - জাভাতে যাচাই করা ব্যতিক্রম এবং লোকেরা এটিকে বোকা বানাতে catchesকিছুই করেনি। আমি মনে করি সম্ভবত অবৈধ অবস্থায় ক্রিয়াকলাপ চালিয়ে যাওয়ার পরিবর্তে সিস্টেমটি ফুটিয়ে তোলা আরও ভাল।
— নথিংস ইম্পসিবল
2
@ ভু: নন-অযোগ্য রেফারেন্স টাইপের অ্যারেগুলি অনেক কারণে শক্ত। অনেকগুলি সম্ভাব্য সমাধান রয়েছে এবং এগুলির সমস্তই বিভিন্ন অপারেশনে ব্যয় আরোপ করে। সুপারকার্টের পরামর্শ হ'ল কোনও উপাদান নির্ধারিত হওয়ার আগে আইনত পাঠ করা যায় কিনা তা ট্র্যাক করা, যা ব্যয় আরোপ করে। ইতিমধ্যে অ্যারের দৃশ্যমান হওয়ার আগে প্রতিটি উপাদানটিতে একটি ইনিশিয়ালাইজার চলমান তা নিশ্চিত করা, যা ব্যয়ের একটি আলাদা সেট চাপিয়ে দেয়। সুতরাং এখানে ঘষা: এই কৌশলগুলির মধ্যে যে কোনওটি চয়ন করুন তা বিবেচনা না করেই কেউ অভিযোগ করতে যাচ্ছেন যে এটি তাদের পোষা প্রাণীর দৃশ্যের জন্য কার্যকর নয় । এটি বৈশিষ্ট্যের বিরুদ্ধে গুরুতর বিষয়।
— এরিক লিপার্ট
28

নাল মূল্য অভাব প্রতিনিধিত্ব করার জন্য একটি খুব বৈধ উদ্দেশ্য পরিবেশন করে।

আমি বলব আমি নালীর অপব্যবহার এবং আমার মাথাব্যথা ও যন্ত্রণা সম্পর্কে তারা জানি যেগুলি বিশেষত উদারপন্থীভাবে ব্যবহার করার সময় আমি সবচেয়ে সোচ্চার ব্যক্তি।

আমার ব্যক্তিগত অবস্থান হল লোকেরা কেবল তখনই নাল ব্যবহার করতে পারে যখন তারা এটি প্রয়োজনীয় এবং উপযুক্তটিকে ন্যায়সঙ্গত করতে পারে।

নালদের ন্যায্যতা প্রমাণ করার উদাহরণ:

মৃত্যুর তারিখটি সাধারণত একটি অবনমিত ক্ষেত্র। মৃত্যুর তারিখ সহ তিনটি সম্ভাব্য পরিস্থিতি রয়েছে। হয় ব্যক্তি মারা গিয়েছে এবং তারিখটি জানা যায়, ব্যক্তি মারা গিয়েছে এবং তারিখটি অজানা, বা ব্যক্তি মৃত নয় এবং সুতরাং মৃত্যুর তারিখের অস্তিত্ব নেই।

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

তথ্য সঠিকভাবে পরিস্থিতি উপস্থাপন করা প্রয়োজন।

ব্যক্তি মৃত্যুর তারিখটি জানা যায় (3/9/1984)

সরল, '3/9/1984'

ব্যক্তি মৃত্যুর তারিখটি অজানা

তাহলে সেরা কি? নাল , '0/0/0000', বা '01 / 01/1869 '(বা আপনার ডিফল্ট মান যাই হোক না কেন?)

ব্যক্তি মৃত্যুর তারিখ প্রযোজ্য নয়

তাহলে সেরা কি? নাল , '0/0/0000', বা '01 / 01/1869 '(বা আপনার ডিফল্ট মান যাই হোক না কেন?)

সুতরাং প্রতিটি মান মনে করি ...

  • নাল , এতে আপনার উদ্বেগ ও উদ্বেগ রয়েছে যা আপনার সতর্ক হওয়া দরকার, দুর্ঘটনাক্রমে এটি নিশ্চিত করেই এটি চালিত করার চেষ্টা করা উচিত এটি প্রথমে বাতিল নয় উদাহরণস্বরূপ এটি একটি ব্যতিক্রম ছুঁড়ে মারবে, তবে এটি প্রকৃত পরিস্থিতিকেও সর্বোত্তমভাবে উপস্থাপন করে ... যদি ব্যক্তি মারা না যায় মৃত্যুর তারিখের অস্তিত্ব নেই ... এটি কিছুই নয় ... এটি নাল ...
  • 0/0/0000 , কিছু ভাষায় এটি ঠিক হতে পারে এবং কোনও তারিখের উপযুক্ত উপস্থাপনাও হতে পারে। দুর্ভাগ্যক্রমে কিছু ভাষা এবং বৈধতা এটিকে একটি অবৈধ ডেটটাইম হিসাবে প্রত্যাখ্যান করবে যা এটি বেশিরভাগ ক্ষেত্রেই অগ্রাহ্য করে।
  • 1/1/1869 (বা আপনার ডিফল্ট ডেটটাইম মানটি যাই হোক না কেন) , এখানে সমস্যা হ্যান্ডেল করা জটিল। আপনি এটির মূল্যমানের অভাব হিসাবে এটি ব্যবহার করতে পারেন, যদি আমার সমস্ত রেকর্ডের ফিল্টার করতে চাই তবে আমার মৃত্যুর তারিখ নেই? আমি সহজেই সেই তারিখে মৃত্যুবরণকারী ব্যক্তিদের সহজেই ফিল্টার করে ফেলতে পারি যা ডেটা অখণ্ডতার সমস্যার কারণ হতে পারে।

আসলে মাঝে মাঝে আপনাকে হয় না কিছুই প্রতিনিধিত্ব করতে এবং নিশ্চিত কখনও কখনও একটি পরিবর্তনশীল যে ধরনের জন্য ভাল কাজ করে, কিন্তু প্রায়ই পরিবর্তনশীল ধরনের কিছুই প্রতিনিধিত্ব করতে সক্ষম হতে হবে প্রয়োজন।

আমার কাছে আপেল না থাকলে আমার কাছে ০ টি আপেল আছে, তবে আমি জানি না আমার কাছে কতগুলি আপেল আছে?

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

— RualStorge
সূত্র
37
Null serves a very valid purpose of representing a lack of value.একটি Optionবা Maybeটাইপ টাইপ সিস্টেমটিকে বাইপাস না করে এই খুব কার্যকর উদ্দেশ্যটি সরবরাহ করে।
— ডোভাল
34
কেউই বিতর্ক করছেন না যে মূল্যমানের অভাব হওয়া উচিত নয়, তারা যুক্তি দিচ্ছেন যে যে মানগুলি অনুপস্থিত হতে পারে তাদের প্রতিটি মান সম্ভাব্য অনুপস্থিত হওয়ার পরিবর্তে স্পষ্টতই চিহ্নিত করা উচিত ।
2
আমার ধারণা রুলস্টোর্জ এসকিউএল সম্পর্কিত ছিল, কারণ এখানে এমন শিবির রয়েছে যা প্রতিটি কলামকে চিহ্নিত করা উচিত NOT NULL। যদিও আমার প্রশ্ন
— আরডিবিএমএসের
5
"মূল্য নেই" এবং "অজানা মান" এর মধ্যে পার্থক্য করার জন্য +1
— ডেভিড
2
এটি কি কোনও ব্যক্তির রাষ্ট্রকে আলাদা করার জন্য আরও অর্থবোধ করে না? অর্থাত্ একটি Personধরণের টাইপের একটি stateক্ষেত্র রয়েছে State, যা Aliveএবং এর বৈষম্যমূলক ইউনিয়ন Dead(dateOfDeath : Date)।
— জন-হ্যানসন
10

"অন্য ভাষাগুলির কাছে যেমন আছে তেমন আমি যেতে পারব না," এটিও জোনেসদের সাথে চালিয়ে যাওয়ার মতো। যে কোনও নতুন ভাষার একটি প্রধান বৈশিষ্ট্য হ'ল অন্যান্য ভাষাগুলিতে বিদ্যমান পাঠাগারগুলির সাথে আন্তঃসংযোগ স্থাপনের দক্ষতা (পড়ুন: সি)। যেহেতু সি নাল পয়েন্টার রয়েছে, আন্তঃব্যবহারযোগ্যতা স্তরটি অগত্যা নাল ধারণাটি প্রয়োজন (বা অন্য কোনও "উপস্থিত নেই" সমতুল্য যা আপনি এটি ব্যবহার করার পরে প্রবাহিত হবে)।

ভাষা ডিজাইনার অপশন প্রকারগুলি ব্যবহার করতে এবং জিনিসগুলি নালাগুলির জন্য যে কোনও জায়গায় নাল পথটি পরিচালনা করতে আপনাকে বাধ্য করতে পারে। এবং এটি অবশ্যই কম বাগের দিকে নিয়ে যাবে।

তবে (বিশেষত জাভা এবং সি # এর জন্য তাদের পরিচিতির সময় এবং তাদের লক্ষ্য শ্রোতার কারণে) এই আন্তঃব্যবহারযোগ্যতা স্তরটির বিকল্প বিকল্পগুলি ব্যবহার করা যদি তাদের গ্রহণকে টর্পডো না করে তবে ক্ষতি হতে পারে। হয় বিকল্প ধরণটি পুরো পথ পেরিয়ে গেছে, 90 এর দশকের মাঝামাঝি থেকে সি ++ প্রোগ্রামারদের মধ্যে হেলাকে বিরক্ত করে - বা আন্তঃব্যবহারযোগ্যতা স্তরটি শূন্যতার মুখোমুখি হওয়ার সময় ব্যতিক্রম ছুঁড়ে ফেলা হবে, 90 এর দশকের শেষের দিকে সি ++ প্রোগ্রামারগুলিকে নরকে বিরক্ত করে। ..

— Telastyn
সূত্র
3
প্রথম অনুচ্ছেদটি আমার কাছে বোধগম্য নয়। আপনার প্রস্তাবিত আকারে জাভাতে সি ইন্টারপ নেই (জেএনআই রয়েছে তবে এটি ইতিমধ্যে উল্লেখের সাথে সম্পর্কিত প্রতিটি কিছুর জন্য এক ডজন হুপের উপর দিয়ে ঝাঁপিয়ে পড়ে ; এছাড়াও এটি ব্যবহারে খুব কমই ব্যবহার করা হয়), অন্যান্য "আধুনিক" ভাষার জন্য একই।
@ ডেলান - দুঃখিত, আমি সি # এর সাথে আরও বেশি পরিচিত, যার মধ্যে এই ধরণের ইন্টারপ রয়েছে। আমি বরং ধরে নিয়েছি যে জাভা গ্রন্থাগারগুলির অনেকগুলি নীচে JNI ব্যবহার করে use
— টেলাস্টিন
6
নালকে অনুমতি দেওয়ার জন্য আপনি একটি ভাল যুক্তি দিয়েছিলেন, তবে আপনি এটি উত্সাহিত ছাড়াই নালকে অনুমতি দিতে পারেন । স্কালার এটির একটি ভাল উদাহরণ। এটা তোলে অঙ্গীভূতভাবে জাভা API গুলি নাল ব্যবহার interoperate করতে পারেন, কিন্তু আপনি একটি ইন এটি মোড়ানো করার পরামর্শ দেওয়া করছি Scala, যা মতই সহজ মধ্যে ব্যবহারের জন্য । অনুশীলনে, লোকেরা এটির সুবিধাগুলি দেখতে খুব বেশি সময় নেয় না । Optionval x = Option(possiblyNullReference)Option
— কার্ল বিলেফেল্ট
1
অপশনের ধরণগুলি (স্ট্যাটিকালি যাচাই করা হয়েছে) প্যাটার্ন ম্যাচিংয়ের সাথে হাতছাড়া হয়ে যায়, যা সি # দুর্ভাগ্যক্রমে নেই। এফ # যদিও করে, এবং এটি দুর্দান্ত।
— স্টিভেন এভার্স
1
@ স্টিভেভার্স বেসরকারী নির্মাতা, সিল করা অভ্যন্তরীণ ক্লাস এবং একটি Matchপদ্ধতি যা প্রতিনিধিদের যুক্তি হিসাবে গ্রহণ করে এমন একটি বিমূর্ত বেস ক্লাস ব্যবহার করে এটি জাল করা সম্ভব । তারপরে আপনি ল্যাম্বদা এক্সপ্রেশনগুলিতে Match(নাম যুক্তি ব্যবহারের জন্য বোনাস পয়েন্ট) পাস করেন এবং ডানটিকে Matchকল করুন।
— ডোভাল
7

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

অনুমোদন nullরেফারেন্স (এবং পয়েন্টার) এই ধারণার একটি মাত্র বাস্তবায়ন, এবং সম্ভবত এটি সবচেয়ে জনপ্রিয় যদিও এটির সমস্যাগুলি জানা রয়েছে: সি, জাভা, পাইথন, রুবি, পিএইচপি, জাভাস্ক্রিপ্ট, ... সমস্ত একইরকম ব্যবহার করে null।

কেন? ঠিক আছে, বিকল্প কি?

যেমন Haskell, যেমন কার্মিক ভাষায় আপনি আছেন Optionবা Maybeটাইপ; তবে এগুলি নির্মিত:

  • প্যারামেট্রিক প্রকারের
  • বীজগণিত তথ্য প্রকার

এখন, মূল সি, জাভা, পাইথন, রুবি বা পিএইচপি কি সেই বৈশিষ্ট্যগুলির কোনওটিকে সমর্থন করেছিল? জাভা এর ত্রুটিযুক্ত জেনেরিকগুলি ভাষার ইতিহাসে সাম্প্রতিক এবং আমি অন্যথায় সন্দেহ করি যে অন্যরা এমনকি এগুলি প্রয়োগ করে।

ওখানে তোমার আছে। nullসহজ, প্যারামেট্রিক বীজগণিত ডেটা ধরণের শক্ত হয়। সহজ সরল বিকল্পের জন্য লোকেরা গিয়েছিল।

— ম্যাথিউ এম।
সূত্র
"নাল জন্য সহজ +1, প্যারাম্যাট্রিক বীজগণিত ডেটা ধরণের শক্ত হয়।" তবে আমি মনে করি এটি প্যারামেট্রিক টাইপিং এবং এডিটি আরও শক্ত হওয়ার বিষয় ছিল না; এটা ঠিক যে তারা প্রয়োজনীয় হিসাবে অনুধাবন করা হয় না। অন্যদিকে জাভা যদি কোনও অবজেক্ট সিস্টেম ছাড়াই চালিত হয় তবে তা ফ্লপ হয়ে যেত; ওওপি একটি "শোস্টোপিং" বৈশিষ্ট্য ছিল, এটি যদি আপনার না থাকে তবে কারও আগ্রহ ছিল না।
— ডোভাল
@ দোভাল: ঠিক আছে, জাফার জন্য ওওপি প্রয়োজনীয় হতে পারে, তবে এটি সিটির জন্য ছিল না :) তবে এটি সত্য যে জাভা সরল হওয়ার লক্ষ্য ছিল। দুর্ভাগ্যক্রমে লোকেরা ধরেই নিয়েছে যে একটি সাধারণ ভাষা সরল প্রোগ্রামগুলির দিকে পরিচালিত করে, যা কিছুটা অদ্ভুত (ব্রেইনফাক একটি খুব সাধারণ ভাষা ...), তবে আমরা অবশ্যই একমত যে জটিল ভাষা (সি ++ ...) হয় তবুও এক নিরাময়ের জায়গা নয় তারা অবিশ্বাস্যভাবে দরকারী হতে পারে।
— ম্যাথিউ এম।
1
@ ম্যাথিউইউম: রিয়েল সিস্টেমগুলি জটিল। এমন একটি সু-নকশিত ভাষা, যার জটিলতা বাস্তব-বিশ্বের সিস্টেমের সাথে মডেলিংয়ের সাথে মেলে, জটিল সিস্টেমটিকে সাধারণ কোড দিয়ে মডেলিং করতে দেয়। কোনও ভাষাকে আরও সহজলভ্য করার চেষ্টাগুলি প্রোগ্রামারটি যিনি এটি ব্যবহার করছেন তার দিকে জটিলতার চাপ দিন।
— সুপারক্যাট
@ সুপের্যাট: আমি আর একমত হতে পারিনি। অথবা আইনস্টাইন যেমন প্যারাফ্রেস করা হয়েছে: "যতটা সম্ভব সবকিছুকে সহজ করুন, তবে সহজ নয়"।
— ম্যাথিউ এম।
@ ম্যাথিউইউএম: আইনস্টাইন বিভিন্নভাবে বুদ্ধিমান ছিলেন। যে ভাষাগুলি "সবকিছুই একটি অবজেক্ট, এটি একটি রেফারেন্স যার মধ্যে Object" সংরক্ষণ করা যেতে পারে "এটি ধরে নিতে ব্যর্থ হয়েছে যে ব্যবহারিক অ্যাপ্লিকেশনগুলিকে ভাগ করা যায় না এমন পরিবর্তনীয় অবজেক্ট এবং শ্যায়েলেবল অবিচ্ছিন্ন অবজেক্ট (উভয়ের উভয়েরই মূল্যবোধের মতো আচরণ করা উচিত) পাশাপাশি শ্যাওরেবল এবং অপরিবর্তনীয় সত্ত্বা। প্রতিটি Objectকিছুর জন্য একক প্রকারের ব্যবহার এই ধরণের পার্থক্যের প্রয়োজনকে দূর করে না; এগুলি কেবল সঠিকভাবে ব্যবহার করা আরও কঠিন করে তোলে।
— সুপারক্যাট
5

নাল / শূন্য / কেউ নিজেই মন্দ নয়।

আপনি যদি তাঁর বিভ্রান্তিকরভাবে নামী বিখ্যাত স্পেইচ "দ্য বিলিয়ন ডলার ভুল" দেখে থাকেন তবে কোনও ভেরিয়েবল কীভাবে নালাকে ধরে রাখতে সক্ষম হওয়া যায় তা সম্পর্কে টনি হোয়ার কথা বলেছেন । বিকল্প - বিকল্পগুলি ব্যবহার করে - আসলে নাল উল্লেখগুলি থেকে মুক্তি পাওয়া যায় না । পরিবর্তে এটি আপনাকে কোন ভেরিয়েবলগুলি নাল ধরে রাখার অনুমতি দেয় এবং কোনটি নয় তা নির্দিষ্ট করার অনুমতি দেয়।

প্রকৃতপক্ষে, আধুনিক ভাষাগুলি যা সঠিক ব্যতিক্রম হ্যান্ডলিং বাস্তবায়ন করে, নাল বিন্যাস ত্রুটি অন্য কোনও ব্যতিক্রমের চেয়ে আলাদা নয় - আপনি এটি খুঁজে পেয়েছেন, আপনি এটি ঠিক করেছেন। নাল রেফারেন্সের কিছু বিকল্প (উদাহরণস্বরূপ নাল অবজেক্ট প্যাটার্ন) ত্রুটিগুলি আড়াল করে, ফলে অনেকক্ষণ পরে নিঃশব্দে ব্যর্থ হয়ে পড়ে। আমার মতে, দ্রুত ব্যর্থ হওয়া আরও ভাল ।

সুতরাং প্রশ্নটি তখন, কেন ভাষাগুলি বিকল্পগুলি প্রয়োগ করতে ব্যর্থ হয়? প্রকৃতপক্ষে, সি ++ এর সর্বকালের তর্কযোগ্যভাবে সর্বাধিক জনপ্রিয় ভাষাতে অবজেক্ট ভেরিয়েবলগুলি সংজ্ঞায়িত করার ক্ষমতা রয়েছে যা নির্ধারিত হতে পারে না NULL। টনি হোয়ের তার বক্তব্যে উল্লিখিত "নাল সমস্যা" এর সমাধান এটি। পরবর্তী সর্বাধিক জনপ্রিয় টাইপ করা ভাষা জাভা কেন নেই? কেউ জিজ্ঞাসা করতে পারে কেন এটি সাধারণভাবে বিশেষত এর টাইপ সিস্টেমে এতগুলি ত্রুটি রয়েছে। আমি মনে করি না যে আপনি সত্যই বলতে পারেন যে ভাষাগুলি পদ্ধতিগতভাবে এই ভুল করে। কিছু করেন, কিছু করেন না।

— বিটি
সূত্র
1
বাস্তবায়নের দৃষ্টিকোণ থেকে জাভার সবচেয়ে বড় শক্তিগুলির মধ্যে একটি, তবে ভাষার দৃষ্টিকোণ থেকে দুর্বলতাগুলি হ'ল কেবল একটি অ-আদিম ধরণের: প্রমিসিউসু অবজেক্ট রেফারেন্স। এটি প্রচুর পরিমাণে রানটাইমকে সহজতর করে, কিছু অতি হালকা ওজনের জেভিএম বাস্তবায়নকে সম্ভব করে তোলে। তবে সেই নকশাটির অর্থ হ'ল প্রতিটি ধরণের অবশ্যই একটি ডিফল্ট মান থাকতে হবে এবং প্রমিসিউস অবজেক্ট রেফারেন্সের জন্য কেবল সম্ভাব্য ডিফল্ট null।
— সুপারক্যাট
ভাল, যে কোনও হারে একটি মূল মূলক নয়। ভাষার দৃষ্টিকোণ থেকে এটি কেন দুর্বলতা? আমি বুঝতে পারি না যে কেন এই সত্যটির প্রয়োজন হয় যে প্রতিটি ধরণের একটি ডিফল্ট মান থাকে (বা বিপরীতে কেন একাধিক মূল ধরণের ধরণের ডিফল্ট মান না রাখার অনুমতি দেয়), বা কেন এটি দুর্বলতা।
— বিটি
ক্ষেত্র বা অ্যারের উপাদানটি আর কোন ধরণের অ-আদিম হতে পারে? দুর্বলতাটি হ'ল কিছু রেফারেন্স সনাক্তকরণের encapsulate করতে ব্যবহৃত হয় এবং কিছু তার দ্বারা চিহ্নিত বস্তুর মধ্যে থাকা মানগুলি encapsulate করতে ব্যবহৃত হয়। পরিচয় encapsulate করতে ব্যবহৃত রেফারেন্স-টাইপ ভেরিয়েবলের nullজন্য, কেবলমাত্র বোধগম্য ডিফল্ট। মানগুলি এনক্যাপসুলেট করার জন্য ব্যবহৃত রেফারেন্সগুলি তবে কোনও ক্ষেত্রে বুদ্ধিমান ডিফল্ট উদাহরণ তৈরি করতে পারে বা ক্ষেত্রে বুদ্ধিমান ডিফল্ট আচরণ থাকতে পারে। কীভাবে রেফারেন্সগুলি আচরণ করা উচিত তার অনেকগুলি দিক নির্ভর করে যে তারা কীভাবে মান
— সজ্জিত করে
... জাভা টাইপ সিস্টেমের তা প্রকাশ করার কোনও উপায় নেই। যদি fooএকটি মাত্র সুত্র ধরে int[]ধারণকারী {1,2,3}এবং কোড চায় fooএকটি একটি রেফারেন্স রাখা int[]ধারণকারী {2,2,3}, অর্জন করার দ্রুততম উপায় যে বাড়ায় হবে foo[0]। কোড যদি কোনও পদ্ধতিটিকে fooধারণ করে রাখতে চায় তবে {1,2,3}, অন্য পদ্ধতিটি অ্যারে পরিবর্তন করবে না বা এমন বিন্দুটি অতিক্রম fooকরবে না যেখানে এটি সংশোধন করতে চাইবে, এটি অর্জনের দ্রুততম উপায়টি অ্যারের সাথে একটি রেফারেন্স পাস করা হবে। জাভাতে যদি "অল্পকালীন পঠনযোগ্য কেবলমাত্র উল্লেখ" টাইপ থাকে, তবে ...
— সুপারক্যাট
... একটি অল্পকালীন রেফারেন্স হিসাবে অ্যারেটি নিরাপদে পাস করা যেতে পারে এবং একটি পদ্ধতি যা এর মান ধরে রাখতে চেয়েছিল তা জানতে পারে যে এটির অনুলিপি করা দরকার। এ জাতীয় ধরণের অভাবে, অ্যারের সামগ্রীগুলি নিরাপদে প্রকাশের একমাত্র উপায় হ'ল এটির অনুলিপি তৈরি করা বা কেবল সেই উদ্দেশ্যে তৈরি করা কোনও বস্তুতে এটি আবদ্ধ করা।
— সুপারক্যাট
4

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

উদাহরণস্বরূপ, আমি যদি একটি সাধারণ স্ক্রিপ্ট লিখতে চাই যা কোনও ফাইলের সাথে কাজ করে তবে আমি সিউডোকোড লিখতে পারি:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

joebloggs.txt উপস্থিত না থাকলে এবং এটি কেবল ব্যর্থ হবে। বিষয়টি হ'ল, সহজ স্ক্রিপ্টগুলির জন্য যা সম্ভবত ঠিক আছে এবং অনেক জটিল কোডে অনেক পরিস্থিতিতে আমি জানি এটি বিদ্যমান এবং ব্যর্থতা ঘটবে না তাই আমাকে আমার সময় নষ্টগুলি পরীক্ষা করতে বাধ্য করতে হবে। নিরাপদ বিকল্পগুলি আমাকে সম্ভাব্য ব্যর্থতার অবস্থার সাথে সঠিকভাবে ডিল করতে বাধ্য করে তাদের সুরক্ষা অর্জন করে তবে প্রায়শই আমি এটি করতে চাই না, আমি কেবল এগিয়ে যেতে চাই।

— জ্যাক এইডলি
সূত্র
13
এবং এখানে আপনি নাল দিয়ে ঠিক কী ভুল হয়েছে তার একটি উদাহরণ দিয়েছেন। যথাযথভাবে প্রয়োগ করা "ওপেনফিল" ফাংশনটিতে একটি ব্যতিক্রম (ফাইল অনুপস্থিতের জন্য) নিক্ষেপ করা উচিত যা ঘটেছে তার সঠিক ব্যাখ্যা দিয়ে ঠিক সেখানেই কার্যকর করা বন্ধ করবে। পরিবর্তে যদি এটি নাল ফেরায় এটি আরও (থেকে for line in file) প্রচার করে এবং অর্থহীন নাল রেফারেন্স ব্যতিক্রম নিক্ষেপ করে, যা এই জাতীয় কোনও সাধারণ প্রোগ্রামের জন্য ঠিক আছে তবে আরও জটিল সিস্টেমে রিয়েল ডিবাগিং সমস্যার কারণ হয়ে থাকে। যদি নালগুলি উপস্থিত না থাকে তবে "ওপেনফাইলে" ডিজাইনার এই ভুল করতে সক্ষম হবেন না।
— এমপিপিও
2
+1 এর জন্য "কারণ প্রোগ্রামিং ভাষাগুলি প্রযুক্তিগতভাবে সঠিক হওয়ার চেয়ে সাধারণত ব্যবহারিকভাবে ডিজাইন করা হয়"
— মার্টিন বা
2
আমার জানা প্রত্যেকটি বিকল্প আপনাকে একক সংক্ষিপ্ত অতিরিক্ত পদ্ধতি কল (মরিচা উদাহরণ let file = something(...).unwrap():) দিয়ে ব্যর্থ-অন-নাল করতে দেয় । আপনার পিওভির উপর নির্ভর করে এটি ত্রুটিগুলি পরিচালনা না করার একটি সহজ উপায় বা একটি সংঘাতের দাবী যা শূন্যতা ঘটতে পারে না। নষ্ট হওয়া সময়টি ন্যূনতম এবং আপনি অন্য জায়গাগুলিতে সময় সাশ্রয় করেন কারণ কোনও কিছু নাল হতে পারে কিনা তা খুঁজে বের করার দরকার নেই। আরেকটি সুবিধা (যা নিজে থেকে অতিরিক্ত কলের মূল্য হতে পারে) হ'ল আপনি ত্রুটি কেসটিকে স্পষ্টভাবে উপেক্ষা করবেন; যখন এটি ব্যর্থ হয় তখন সমস্যাটি কী হয়েছিল এবং কোথায় ঠিক করার দরকার তা নিয়ে সন্দেহ নেই।
4
@ এমপ্রিপিও সমস্ত ভাষা ব্যতিক্রম এবং / অথবা ব্যতিক্রম হ্যান্ডলিং (একটি লা ট্রাই / ক্যাচ) সমর্থন করে না। এবং ব্যতিক্রমগুলি পাশাপাশি আপত্তিজনক ব্যবহার করা যেতে পারে - "প্রবাহ নিয়ন্ত্রণ হিসাবে ব্যতিক্রম" একটি সাধারণ অ্যান্টি-প্যাটার্ন। এই দৃশ্যটি - কোনও ফাইল নেই AF এটি অ্যান্টি-প্যাটার্নের সর্বাধিক প্রায়শই উদ্ধৃত উদাহরণ আফাইক। এটি প্রদর্শিত হবে আপনি একটি খারাপ অনুশীলনকে অন্যটির সাথে প্রতিস্থাপন করছেন।
— ডেভিড
8
@ এমপ্রিও if file exists { open file }একটি রেসের শর্তে ভুগছে। কোনও ফাইল খোলার ক্ষেত্রে সফল হবে কিনা তা জানার একমাত্র নির্ভরযোগ্য উপায় হ'ল এটি খোলার চেষ্টা করা।
4

NULL(বা nil, বা Nil, বা null, বা Nothingবা যা আপনার পছন্দের ভাষায় বলা হয়) এর স্পষ্ট, ব্যবহারিক ব্যবহার রয়েছে ।

যে ভাষাগুলির একটি ব্যতিক্রম সিস্টেম নেই (উদাহরণস্বরূপ সি) একটি নাল পয়েন্টারটি ত্রুটির চিহ্ন হিসাবে ব্যবহার করা যেতে পারে যখন পয়েন্টারটি ফেরত দেওয়া উচিত। উদাহরণ স্বরূপ:

char *buf = malloc(20);
if (!buf)
{
    perror("memory allocation failed");
    exit(1);
}

এখানে NULLথেকে ফিরে আসা malloc(3)ব্যর্থতার চিহ্নিতকারী হিসাবে ব্যবহৃত হয়।

যখন পদ্ধতি / ফাংশন আর্গুমেন্টে ব্যবহৃত হয়, এটি আর্গুমেন্টের জন্য ডিফল্ট ব্যবহার নির্দেশ করতে পারে বা আউটপুট আর্গুমেন্টকে উপেক্ষা করে। নীচে উদাহরণ।

এমনকি ব্যতিক্রম প্রক্রিয়াধীন সেই ভাষার ক্ষেত্রেও নাল পয়েন্টারটি নরম ত্রুটির ইঙ্গিত হিসাবে ব্যবহার করা যেতে পারে (এটি, ত্রুটিগুলি যা পুনরুদ্ধারযোগ্য) বিশেষত যখন ব্যতিক্রম হ্যান্ডলিং ব্যয়বহুল (যেমন উদ্দেশ্য-সি):

NSError *err = nil;
NSString *content = [NSString stringWithContentsOfURL:sourceFile
                                         usedEncoding:NULL // This output is ignored
                                                error:&err];
if (!content) // If the object is null, we have a soft error to recover from
{
    fprintf(stderr, "error: %s\n", [[err localizedDescription] UTF8String]);
    if (!error) // Check if the parent method ignored the error argument
        *error = err;
    return nil; // Go back to parent layer, with another soft error.
}

এখানে, নরম ত্রুটি প্রোগ্রামটি ধরা না পড়লে ক্রাশের কারণ হয় না। এটি জাভাগুলির মতো ক্রেজি ট্রাই-ক্যাচকে সরিয়ে দেয় এবং প্রোগ্রাম প্রবাহে আরও ভাল নিয়ন্ত্রণ রাখতে পারে কারণ নরম ত্রুটিগুলি বাধাগ্রস্ত হয় না (এবং বাকি কয়েকটি শক্ত ব্যতিক্রম সাধারণত পুনরুদ্ধারযোগ্য নয় এবং বাকী থাকে না)

— ম্যাক্সথন চ্যান
সূত্র
5
সমস্যাটি হ'ল ভেরিয়েবলগুলির মধ্যে পার্থক্য করার কোনও উপায় নেই যা এর সাথে থাকা nullউচিত নয়। উদাহরণস্বরূপ, আমি যদি জাভাতে 5 টি মান ধারণ করে এমন একটি নতুন ধরণের চাই, তবে আমি একটি এনাম ব্যবহার করতে পারি, তবে আমি যা পাই তা হ'ল একটি মান যা 6 মান (যে 5 টি আমি চেয়েছিলাম + null) রাখতে পারি। এটি টাইপ সিস্টেমে একটি ত্রুটি।
— ডোভাল
@ ডোভাল যদি এই পরিস্থিতিটি হয় তবে কেবল নুলকে একটি অর্থ নির্ধারণ করুন (বা যদি আপনার একটি ডিফল্ট থাকে তবে এটি ডিফল্ট মানের প্রতিশব্দ হিসাবে বিবেচনা করুন) বা ন্যূনুএল (যা কখনই প্রথম স্থানে প্রদর্শিত হবে না) নরম ত্রুটির চিহ্নিতকারী হিসাবে ব্যবহার করুন (অর্থাত্ ত্রুটি তবে কমপক্ষে এখনও ক্র্যাশ হচ্ছে না)
— ম্যাক্সথন চ্যান
1
@ ম্যাক্সটনচান Nullকেবল তখনই একটি অর্থ নির্ধারণ করা যেতে পারে যখন কোনও ধরণের মানগুলি কোনও ডেটা না রাখে (যেমন এনাম মান)। যত তাড়াতাড়ি আপনার মানগুলি আরও জটিল কিছু (যেমন একটি স্ট্রাক্ট) হয়ে থাকে, nullসেই ধরণের জন্য অর্থ বোঝার কোনও অর্থ বরাদ্দ করা যায় না। nullস্ট্রাক্ট বা তালিকা হিসাবে কোনও ব্যবহার করার উপায় নেই । এবং আবারও, nullত্রুটি সংকেত হিসাবে ব্যবহার করতে সমস্যা হ'ল আমরা কী বলতে পারি না যে নাল ফিরে আসতে পারে বা নাল গ্রহণ করতে পারে। আপনার প্রোগ্রামের যে কোনও পরিবর্তনশীল nullহ'ল যদি না আপনি nullপ্রতিটি একক ব্যবহারের আগে প্রতি একককে পরীক্ষা করার জন্য অত্যন্ত নিখুঁত হন , যা কেউ করে না।
— ডোভাল
1
@ দোভাল: nullব্যবহারযোগ্য ডিফল্ট মান হিসাবে উদ্বোধনযোগ্য রেফারেন্স ধরণের বিষয়ে কোনও বিশেষ অন্তর্নিহিত অসুবিধা হবে না (যেমন stringপূর্ববর্তী সাধারণ বস্তু মডেলের অধীনে যেভাবে খালি স্ট্রিং হিসাবে আচরণের ডিফল্ট মান রয়েছে )। যা প্রয়োজন হত তা হ'ল অ-ভার্চুয়াল সদস্যদের callপরিবর্তে ভাষা ব্যবহারের জন্য callvirt।
— সুপারক্যাট
@ সুপের্যাট এটি একটি ভাল বিষয়, তবে এখন অপরিবর্তনীয় এবং অপরিবর্তনীয় প্রকারের মধ্যে পার্থক্য করার জন্য আপনার সমর্থন যোগ করার দরকার নেই? আমি নিশ্চিত নই যে এটি কোনও ভাষায় যুক্ত করার জন্য কতটা তুচ্ছ।
— ডোভাল
4

দুটি সম্পর্কিত, তবে কিছুটা আলাদা সমস্যা রয়েছে:

  1. nullআদৌ কি থাকা উচিত ? বা Maybe<T>নাল দরকারী যেখানে আপনার সর্বদা ব্যবহার করা উচিত ?

  2. সমস্ত রেফারেন্স নালাগুলি হওয়া উচিত? তা না হলে কোনটি ডিফল্ট হওয়া উচিত?

    প্রোগ্রামাররা যেভাবে ব্যবহৃত হয় তার থেকে খুব বেশি আলাদা না হয়ে স্পষ্টভাবে অযোগ্য রেফারেন্স প্রকারগুলি string?বা এর অনুরূপ হিসাবে সম্পর্কিত সমস্যাগুলির nullকারণগুলি বেশিরভাগ (তবে সমস্ত নয়) এড়াতে পারে।

আমি কমপক্ষে আপনার সাথে একমত হই যে সমস্ত তথ্য উল্লেখযোগ্য হওয়া উচিত নয়। তবে নাল এড়ানো এড়ানো জটিলতা ছাড়া নয়:

.NET default<T>ম্যানেজড কোড দ্বারা প্রথমে অ্যাক্সেস করার আগে সমস্ত ক্ষেত্রকে সূচনা করে । এর অর্থ হ'ল রেফারেন্স ধরণের জন্য আপনার প্রয়োজন হয় nullবা সমমানের কিছু এবং সেই মানের প্রকারগুলি কোড চালনা ছাড়াই এক ধরণের শূন্যের সাথে সূচনা করা যেতে পারে । যদিও এই দু'জনেরই মারাত্মক ডাউনসাইড রয়েছে, defaultআরম্ভের সরলতার ফলে সেই ডাউনসাইডকে ছাড়িয়ে যেতে পারে।

  • জন্য দৃষ্টান্ত ক্ষেত্র আপনি প্রকাশক সামনে ক্ষেত্র আরম্ভের এমন পদ্ধতির মাধ্যমে এই সমস্যা এড়ানোর কাজ করতে পারেন thisপরিচালিত কোডে পয়েন্টার। C # এর সাথে তুলনা করে কনস্ট্রাক্টর চেইন থেকে বিভিন্ন সিনট্যাক্স ব্যবহার করে স্পেস # এই পথে চলে গেছে।

  • জন্য স্ট্যাটিক ক্ষেত্র যদি না আপনি যেহেতু আপনি কেবল লুকাতে পারেন না কি ধরনের কোড একটি ক্ষেত্র সূচনাকারী চালানোর পারে শক্তিশালী সীমাবদ্ধতা জাহির করা এই নিশ্চিত কঠিন thisপয়েন্টার।

  • রেফারেন্স ধরণের অ্যারেগুলি কীভাবে শুরু করবেন? List<T>দৈর্ঘ্যের চেয়ে বৃহত্তর ক্ষমতা সহ একটি অ্যারে দ্বারা সমর্থিত যা বিবেচনা করুন । বাকি উপাদানগুলির কিছু মূল্য থাকা দরকার।

আরেকটি সমস্যা হলো পদ্ধতি মত অনুমতি দেয় না হয় bool TryGetValue<T>(key, out T value)যা আসতে default(T)যেমন valueযদি তারা কিছু খুঁজে না। যদিও এই ক্ষেত্রে তর্ক করা সহজ যে আউট প্যারামিটারটি প্রথমে খারাপ ডিজাইন এবং এই পদ্ধতির পরিবর্তে একটি বৈষম্যমূলক ইউনিয়ন বা সম্ভবত ফিরে আসা উচিত ।

এই সমস্ত সমস্যার সমাধান করা যেতে পারে তবে এটি "নাল নিষিদ্ধ করুন এবং সব ঠিক আছে" এর মতো সহজ নয়।

— CodesInChaos
সূত্র
List<T>এই প্রোগ্রামটিতে সেরা উদাহরণ, কারণ তা করতে হবে পারেন যে যে Tডিফল্ট মান, যে ব্যাকিং দোকান প্রতিটি আইটেম একটি হতে Maybe<T>একটি অতিরিক্ত "isValid" ক্ষেত্র সঙ্গে, এমনকি যখন Tএকটি হল Maybe<U>, বা কোড যে List<T>আচরণ ভিন্নভাবে নির্ভর করে Tনিজেই একটি নলাবদ্ধ টাইপ কিনা upon আমি আরম্ভের বিবেচনা করবে T[]ডিফল্ট মান উপাদান সেই পছন্দগুলি অন্তত মন্দ হতে, কিন্তু এটা অবশ্যই এর মানে হল যে উপাদান প্রয়োজন আছে একটি ডিফল্ট মান।
— সুপারক্যাট
মরিচা 1 পয়েন্ট অনুসরণ করে - কোনও নাল নয়। সিলোন পয়েন্ট 2 অনুসরণ করে - ডিফল্টরূপে নন-নাল। নাল হতে পারে এমন উল্লেখগুলি ইউনিয়ন প্রকারের সাথে স্পষ্টভাবে ঘোষিত হয় যার মধ্যে একটি উল্লেখ বা নাল অন্তর্ভুক্ত থাকে তবে নাল কখনই সরল রেফারেন্সের মান হতে পারে না। ফলস্বরূপ, ভাষাটি সম্পূর্ণ নিরাপদ এবং নলপয়েন্টার এক্সসেপশন নেই কারণ এটি শব্দার্থগতভাবে সম্ভব নয়।
— জিম বাল্টার
2

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

বিভিন্ন ভাষা এবং সিস্টেম বিভিন্ন পন্থা গ্রহণ করে।

  • একটি পদ্ধতির বলার অপেক্ষা রাখে না যে লিখিত হয়নি এমন কিছু পড়ার যে কোনও প্রচেষ্টা তাত্ক্ষণিক ত্রুটি ঘটায়।

  • দ্বিতীয় পদ্ধতির জন্য হ'ল সঞ্চিত মানটি শব্দার্থগতভাবে কার্যকর হওয়ার কোনও উপায় না থাকলেও, এটি পড়ার সম্ভাবনা হওয়ার আগেই প্রতিটি স্থানে কিছু মান সরবরাহ করার কোড প্রয়োজন।

  • তৃতীয় পন্থাটি হ'ল সমস্যাটিকে উপেক্ষা করা এবং "প্রাকৃতিকভাবে" যা ঘটেছিল তা কেবল ঘটতে দেওয়া।

  • চতুর্থ পন্থাটি হ'ল প্রতিটি প্রকারের একটি ডিফল্ট মান থাকতে হবে এবং যে কোনও স্লট যা অন্য কোনও কিছুর সাথে লেখা হয়নি তা সেই মানটিতে ডিফল্ট হবে।

অ্যাপ্রোচ # 4 অ্যাপ্রোচ # 3 এর চেয়ে অনেক বেশি নিরাপদ এবং এটি সাধারণত # 1 এবং # 2 এর চেয়ে কম সস্তা। এরপরে একটি রেফারেন্স ধরণের জন্য ডিফল্ট মানটি কী হওয়া উচিত তা প্রশ্ন ছেড়ে দেয়। অপরিবর্তনীয় রেফারেন্স ধরণের ক্ষেত্রে, এটি অনেক ক্ষেত্রে একটি ডিফল্ট উদাহরণটি সংজ্ঞায়িত করার জন্য অর্থবোধ করে এবং বলে যে এই ধরণের কোনও ভেরিয়েবলের জন্য ডিফল্টটি সেই দৃষ্টান্তের জন্য একটি রেফারেন্স হওয়া উচিত। পরিবর্তনীয় রেফারেন্স ধরণের জন্য, তবে এটি খুব সহায়ক হবে না। লিখিত হওয়ার আগে যদি কোনও পরিবর্তনীয় রেফারেন্স প্রকারটি ব্যবহার করার চেষ্টা করা হয়, তবে সাধারণত চেষ্টা করার ব্যবহারের জায়গায় ফাঁদ ছাড়া আর কোনও নিরাপদ কর্মের ব্যবস্থা নেই।

শব্দার্থকভাবে বলতে গেলে, যদি কারও customersধরণের ধরণের অ্যারে থাকে Customer[20]এবং Customer[4].GiveMoney(23)কোনও কিছু সংরক্ষণ না করেই চেষ্টা করা হয় তবে Customer[4]মৃত্যুদণ্ড কার্যকর করতে ফাঁদে পড়তে চলেছে। যে কেউ তর্ক করতে পারে যে Customer[4]কোডটি চেষ্টা করার অপেক্ষা না করে অপেক্ষা করার পরিবর্তে তাত্ক্ষণিকভাবে ফাঁদে ফেলা উচিত GiveMoney, তবে পর্যাপ্ত ক্ষেত্রে রয়েছে যেখানে এটি স্লট পড়ার পক্ষে দরকারী, এটির কোনও মূল্য নেই এবং তা আবিষ্কার করুন এবং তারপরে এটি ব্যবহার করুন তথ্য, যে পড়ার প্রচেষ্টা নিজেই ব্যর্থ হওয়া প্রায়শই একটি বড় উপদ্রব হতে পারে।

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

— supercat
সূত্র
একটি করবে না Maybe/ Optionটাইপ # 2 সঙ্গে সমস্যা সমাধান, যেহেতু আপনি আপনার অবগতির জন্য একটি মান হবে না এখনো কিন্তু থাকবে ভবিষ্যতে এক, আপনি শুধু সংরক্ষণ করতে পারেন Nothingএকটি Maybe <Ref type>?
— ডোভাল
@ ডোভাল: না, এটি সমস্যার সমাধান করবে না - কমপক্ষে, আবারও নাল রেফারেন্সগুলি প্রবর্তন না করে নয়। কোনও "কিছুই না" এই ধরণের সদস্যের মতো আচরণ করা উচিত? যদি তাই হয়, কোনটি? বা এটি একটি ব্যতিক্রম নিক্ষেপ করা উচিত? কোন ক্ষেত্রে, আপনি nullসঠিকভাবে / সংবেদনশীলভাবে ব্যবহারের চেয়ে আরও ভাল কীভাবে আছেন ?
— সিএইচও
@ ডোভাল: একটি ব্যাকিং ধরণের List<T>একটি T[]বা একটি হওয়া উচিত Maybe<T>? এ এর ব্যাকিং টাইপ সম্পর্কে কী List<Maybe<T>>?
— সুপারক্যাট
@ সুপের্যাট আমি নিশ্চিত নই যেহেতু একটি ব্যাকিং ধরণের কীভাবে একক মান রাখে Maybesense মানে ? ListMaybeMaybe<T>[]
— ডোভাল
@ সিএইচও Nothingশুধুমাত্র টাইপের মানগুলিতে নির্ধারিত হতে পারে Maybe, সুতরাং এটি নির্ধারণের মতো নয় null। Maybe<T>এবং Tদুটি স্বতন্ত্র প্রকার।
— ডোভাল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.