আমার বস্তুটি পরিবর্তনযোগ্য হলে ফাংশনাল প্রোগ্রামিংয়ের প্রসঙ্গে কী ভুল হতে পারে?


9

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

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

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

আমি বিশ্বাস করি আমার নিজের বক্তব্য নীচে নিজেই এই প্রশ্নের উত্তর দেয়। তবে তবুও আমার কিছু উদাহরণ প্রয়োজন যাতে আমি এটি আরও প্রাকৃতিকভাবে অনুভব করতে পারি।

ওও নির্ভরতা পরিচালনা করতে এবং এনক্যাপসুলেশন, পলিমারফিজম ইত্যাদির মতো সরঞ্জামগুলির সাহায্যে সহজ এবং বজায় রাখতে সক্ষম প্রোগ্রাম লিখতে সহায়তা করে

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


1
@Ruben আমি বলতে চাই সবচেয়ে কার্যকরী ভাষায় চপল পরিবর্তনশীল অনুমতি দিই, কিন্তু এটা বিভিন্ন তাদের ব্যবহার করার জন্য যেমন চপল ভেরিয়েবল একটি ভিন্ন ধরনের আছে করা
জে।

1
আমি মনে করি আপনি আপনার প্রথম অনুচ্ছেদে অপরিবর্তনীয় এবং পরিবর্তনীয় হতে পারে?
জে কে।

1
@ জে কে।, তিনি অবশ্যই করেছেন। এটি সংশোধন করার জন্য সম্পাদিত।
ডেভিড আরনো

6
@ রুবেন ফাংশনাল প্রোগ্রামিং একটি দৃষ্টান্ত। এটির জন্য কার্যকরী প্রোগ্রামিং ভাষার প্রয়োজন হয় না। এবং কিছু এফপি ভাষা যেমন এফ # এর বৈশিষ্ট্য রয়েছে
ক্রিস্টোফ

1
@Ruben কোন বিশেষভাবে আমি মধ্যে Haskell Mvars চিন্তা ছিল hackage.haskell.org/package/base-4.9.1.0/docs/... বিভিন্ন ভাষায় আছে অবশ্যই বিভিন্ন সমস্যার সমাধান বা IORefs hackage.haskell.org/package/base-4.11.1.0 /docs/Data-IORef.html যদিও আপনি উভয় monads
jk

উত্তর:


7

আমি মনে করি যে ওও পদ্ধতির সাথে তুলনা করে গুরুত্বটি সর্বোত্তমভাবে প্রদর্শিত হয়

উদাহরণস্বরূপ, বলুন আমাদের একটি অবজেক্ট আছে

Order
{
    string Status {get;set;}
    Purchase()
    {
        this.Status = "Purchased";
    }
}

ওও দৃষ্টান্তে পদ্ধতিটি ডেটার সাথে সংযুক্ত থাকে এবং সেই ডেটাটি পদ্ধতির মাধ্যমে পরিবর্তিত হওয়ার পক্ষে তা বোঝা যায়।

var order = new Order();
order.Purchase();
Console.WriteLine(order.Status); // "Purchased"

ক্রিয়ামূলক দৃষ্টান্তে আমরা ফাংশনের শর্তে একটি ফলাফল সংজ্ঞায়িত করি। একটি ক্রয় করা আদেশ হ'ল একটি আদেশে প্রয়োগ করা ক্রয়ের কার্যের ফলাফল। এটি কয়েকটি বিষয়কে বোঝায় যা আমাদের নিশ্চিত হওয়া উচিত

var order = new Order(); //this is a 'new order'
var purchasedOrder = purchase(order); // this is a 'purchased order'
Console.WriteLine(order.Status); // "New" order is still a 'new order'

আপনি কি অর্ডার আশা করবেন? স্ট্যাটাস == "কিনেছেন"?

এটিও বোঝায় যে আমাদের কাজগুলি আদর্শবান ot অর্থাত। এগুলি দু'বার চালানোতে প্রতিবার একই ফলাফল পাওয়া উচিত।

var order = new Order(); //new order
var purchasedOrder = purchase(order); //purchased order
var purchasedOrder2 = purchase(order); //another purchased order
var purchasedOrder = purchase(purchasedOrder); //error! cant purchase an order twice

ক্রয় ক্রিয়াকলাপ দ্বারা অর্ডার পরিবর্তন করা থাকলে, কেনা অর্ডার 2 ব্যর্থ হবে।

ফাংশনগুলির ফলাফল হিসাবে জিনিসগুলি সংজ্ঞায়িত করে এটি আমাদের সেগুলি ফলাফলগুলি না গণনা ছাড়াই ব্যবহার করতে দেয়। প্রোগ্রামিং পদে যা কার্যকর করা স্থগিত করা হয়।

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

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

যদি কোনও ফাংশন এর ইনপুটটিকে পরিবর্তিত করে তবে আমাদের এ জাতীয় বিষয়গুলি সম্পর্কে আরও বেশি যত্নবান হতে হবে।


ধন্যবাদ !! খুব উপকারী. সুতরাং ক্রয়ের নতুন বাস্তবায়ন এমন হবে Order Purchase() { return new Order(Status = "Purchased") } যাতে স্থিতিটি কেবল পঠিত হয়। ? আবার এই অনুশীলনটি ফাংশন প্রোগ্রামিং দৃষ্টান্তের প্রসঙ্গে কেন আরও প্রাসঙ্গিক? আপনার উল্লিখিত সুবিধাগুলি ওও প্রোগ্রামিংয়েও দেখা যাবে, তাই না?
রাহুলগা_দেব

OO এ আপনি অবজেক্টের প্রত্যাশা করবেন ur আপনি এটিকে অপরিবর্তনীয় করে তুলতে পারেন, তবে তারপরে কেন সম্পূর্ণ কার্যকরী দৃষ্টান্তে যান না
ইওয়ান

আমি মনে করি সমস্যাটি ভিজ্যুয়ালাইজ করতে হচ্ছে কারণ আমি খাঁটি সি # বিকাশকারী যা প্রকৃতির দ্বারা অভিযুক্ত। সুতরাং আপনি যে ভাষায় ফাংশনাল প্রোগ্রামিং গ্রহণ করেন তা কীভাবে 'ক্রয় ()' ফাংশন রিটার্নের ক্রয় ক্রম কোনও শ্রেণি বা বস্তুর সাথে সংযুক্ত করার প্রয়োজন হবে না, তাই না?
রাহুলগা_দেব

3
আপনি ক্রিয়ামূলক সি লিখতে পারেন # আপনার অবজেক্টটিকে স্ট্রাক্টে পরিবর্তন করতে, এটিকে অপরিবর্তনীয় করে তুলুন এবং একটি ফানক <অর্ডার, অর্ডার> ক্রয়
ইওয়ান

12

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

মূল বিষয়টি জিজ্ঞাসা করা হ'ল, অপরিবর্তনীয়তার সেই সুবিধাটি কী? উত্তরটি হল, এটি জটিলতা এড়ায়। বলুন আমাদের দুটি ভেরিয়েবল রয়েছে xএবং y। উভয় মান দিয়ে শুরু 1yযদিও প্রতি 13 সেকেন্ডে দ্বিগুণ। 20 দিনের মধ্যে তাদের প্রত্যেকের মান কত হবে? xহবে 1। এটা সহজ. এটি yআরও জটিল হিসাবে কাজ করার জন্য চেষ্টা করতে হবে। 20 দিনের সময় দিনের কোন সময়? আমি কি দিবালোক সংরক্ষণ অ্যাকাউন্টে গ্রহণ করতে হবে? জটিলতা yবনাম xঠিক তাই অনেক বেশী।

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

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


4
"জটিলতা হ্রাস করার একটি সহজ উপায় হ'ল ডিফল্টরূপে জিনিসগুলি অপরিবর্তনীয় করে তোলা এবং প্রয়োজনের সময় কেবল এগুলি পরিবর্তনযোগ্য করে তোলা": খুব সুন্দর এবং সংক্ষিপ্ত সংক্ষিপ্তসার।
জর্জিও

2
@ ডেভিড আর্নো আপনার যে জটিলতা বর্ণনা করেছেন তা কোড সম্পর্কে বিতর্ক করা শক্ত করে তোলে। আপনি যখন এই কথাটি স্পর্শ করেছিলেন তখন "আপনার কোডটি লেখা শক্ত; পড়া শক্ত; ডিবাগ করা শক্ত; ..." say আমি অপরিবর্তনীয় বস্তু পছন্দ করি কারণ তারা কোডটি কেবলমাত্র নিজেরাই নয়, পর্যবেক্ষকরা যারা পুরো প্রকল্পটি না জেনেও তর্ক করেন তার বিষয়ে যুক্তিযুক্ত কারণগুলি অনেক সহজ করে তোলে।
ডিসে এসেম্বল-নম্বর -5

1
@ রাহুলআরওয়াল, " তবে এই সমস্যাটি কার্যকরী প্রোগ্রামিংয়ের প্রসঙ্গে কেন আরও বিশিষ্ট হয় "। এটা হয় না। আমি মনে করি সম্ভবত আপনি যা জিজ্ঞাসা করছেন তাতে আমি বিভ্রান্ত হচ্ছি কারণ এফপিতে সমস্যাটি খুব কম উজ্জ্বল হওয়ায় এফপি এইভাবে সমস্যাটি এড়িয়ে চলা অপরিবর্তনাকে উত্সাহিত করে।
ডেভিড আরনো

1
@ ডিজেচলিন, " আপনার 13 দ্বিতীয় উদাহরণটি কীভাবে অপরিবর্তনীয় কোড দিয়ে বিশ্লেষণ করা সহজ হতে পারে? " এটি করতে পারে না: yপরিবর্তন করতে হবে; এটি একটি প্রয়োজন কখনও কখনও আমাদের জটিল প্রয়োজনীয়তাগুলি পূরণ করার জন্য জটিল কোড থাকতে হয়। আমি যে বিষয়টিটি তৈরির চেষ্টা করছিলাম তা হ'ল অপ্রয়োজনীয় জটিলতা এড়ানো উচিত। মিউটেশন মানগুলি স্থির মানগুলির চেয়ে সহজাত আরও জটিল, সুতরাং - অপ্রয়োজনীয় জটিলতা এড়াতে - যখন আপনাকে করতে হবে কেবল তখনই মান পরিবর্তন করুন।
ডেভিড আরনো

3
পরিবর্তনশীলতা একটি পরিচয় সংকট তৈরি করে creates আপনার ভেরিয়েবলের আর একক পরিচয় নেই। পরিবর্তে, এর পরিচয় এখন সময়ের উপর নির্ভর করে। প্রতীকীভাবে, একক এক্সের পরিবর্তে, এখন আমাদের একটি পরিবার x_t আছে। ভেরিয়েবলটি ব্যবহার করে যে কোনও কোডে এখন সময় সম্পর্কেও চিন্তিত হতে হবে, উত্তরে উল্লিখিত অতিরিক্ত জটিলতা সৃষ্টি করবে।
অ্যালেক্স ভং

8

ক্রিয়ামূলক প্রোগ্রামিংয়ের প্রসঙ্গে কী ভুল হতে পারে

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

আইএমএইচও এটির কার্যকারিতা এবং অ-কার্যকরী প্রোগ্রামিংয়ের মধ্যে একমাত্র আসল পার্থক্য হ'ল, অ-কার্যকরী কোডে আপনি সাধারণত পার্শ্ব-প্রতিক্রিয়া আশা করতে পারেন, ফাংশনাল প্রোগ্রামিংয়ে, আপনি পাবেন না।

মূলত এটি যদি খারাপ হয় তবে এটি OO বা কার্যকরী প্রোগ্রামিং দৃষ্টান্ত নির্বিশেষে খারাপ, তাই না?

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


4

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

for (elem <- rows map (row => s3 map row)) {
  val elem_str = elem.map(_.toString)

  logger.info("verifying the S3 bucket passed from the ctrl table for each App")
  logger.info(s"Checking on App Code: ${elem head}")

  listS3Buckets(elem_str(1), elem_str(2)) match {

    case Some(allBktsInfo) =>
      logger.info(s"App: ${elem_str head} provided the bucket name as: ${elem_str(3)}")
      if (allBktsInfo.exists(x => x.getName == elem_str(3))) {
        logger.info(s"Provided S3 bucket: ${elem_str(3)} exists")
        println(s"s3 ${elem_str(3)} bucket exists")
      } else {
        logger.info(s"WARNING: Provided S3 bucket ${elem_str(3)} doesn't exists")
        logger.info(s"WARNING: Dropping the App: ${elem_str.head} from backup schedule")
        excludeList += elem_str.head // If the bucket is invalid then we exclude from backup
        println(s"s3 bucket ${elem_str(3)} doesn't exists")
    }

    case None =>
      logger.info(s"WARNING: Provided S3 bucket ${elem_str(3)} doesn't exists")
      logger.info(s"WARNING: Dropping the App: ${elem_str.head} from backup schedule")
      excludeList += elem_str.head // If the bucket is invalid then we exclude from backup
}

আপনি যখন অপরিবর্তনীয়তায় অভ্যস্ত হন, আপনি খুব বেশি সময় অপেক্ষা করলে ডেটা স্ট্রাকচার পরিবর্তনের আশঙ্কা থাকে না, তাই আপনি আরও অবৈধভাবে আপনার অবসর সময়ে যৌক্তিকভাবে পৃথক কাজগুলি করতে পারেন:

val (exists, missing) = rows partition bucketExists
missing foreach {row =>
  logger.info(s"WARNING: Provided S3 bucket ${row("s3_primary_bkt_name")} doesn't exist")
  logger.info(s"WARNING: Dropping the App: ${row("app")} from backup schedule")
}

3

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

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

আমি মনে করি এটি সাধারণভাবে প্রোগ্রামিংয়ের জন্য (কেবলমাত্র কার্যকরী প্রোগ্রামিং নয়) অপরিবর্তনীয় বস্তুগুলিকে তিনটি বিভাগে ভাবার জন্য ভাবা:

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

  2. যে বিষয়গুলিতে কোডগুলি তাদের রেফারেন্স রয়েছে তাদের দ্বারা তাদের পরিবর্তন করার অনুমতি দেবে, কিন্তু যাদের রেফারেন্সগুলি এমন কোনও কোডের সাথে কখনই প্রকাশিত হবে না যা আসলে তাদের পরিবর্তন করবে change এই বস্তুগুলি মানগুলি encapsulate করে, তবে সেগুলি কেবলমাত্র এমন কোডের সাথে ভাগ করা যায় যা তাদের পরিবর্তন করতে না পারে বা এমন কোডগুলিতে প্রকাশ করতে পারে না যে বিশ্বাস করতে পারে।

  3. যে বিষয়গুলি পরিবর্তন করা হবে। এই বিষয়গুলি পাত্রে হিসাবে সেরা দেখা হয় এবং সনাক্তকারী হিসাবে তাদের উল্লেখ ।

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

(*) মাল্টি-থ্রেড কোডগুলিতে, কোনও থ্রেড সম্ভবত মোড়কের কোনও রেফারেন্স দেখতে পাবে, কনটেইনারটিতে থাকা সমস্ত ক্রিয়াকলাপের প্রভাব সেই থ্রেডে দৃশ্যমান হবে তা নিশ্চিত করার জন্য "মেমরি বাধা" ব্যবহার করা প্রয়োজন হতে পারে এটি সম্পূর্ণতার জন্য এখানে উল্লেখ করা একটি বিশেষ মামলা case


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

@ রাহুলআরওয়াল: কোনও বস্তুর সাথে এমন কোনও মানের রেফারেন্স পাওয়া সম্ভব যার অর্থ একই বস্তুর সাথে অন্য রেফারেন্সের অস্তিত্ব দ্বারা প্রভাবিত হয় না, তার একটি পরিচয় রয়েছে যা তাদেরকে একই বস্তুর সাথে অন্য রেফারেন্সের সাথে যুক্ত করে, বা উভয়ই নয়। যদি সত্য-শব্দের স্থিতি পরিবর্তন হয়, তবে হয় সেই রাজ্যের সাথে যুক্ত কোনও জিনিসের মান বা পরিচয় ধ্রুবক হতে পারে, তবে উভয়ই নয় - একটিকেই পরিবর্তন করতে হবে। 50,000 ডলার যা করা উচিত।
সুপারক্যাট

1

ইতিমধ্যে উল্লেখ করা হয়েছে যে, পরিবর্তনীয় রাষ্ট্রের সমস্যাটি মূলত পার্শ্ব প্রতিক্রিয়াগুলির বৃহত্তর সমস্যার একটি সাবক্লাস , যেখানে কোনও ফাংশনের রিটার্ন-টাইপ সঠিকভাবে ফাংশনটি কী করে তা বর্ণনা করে না, কারণ এই ক্ষেত্রে এটি রাষ্ট্রীয় পরিবর্তনও করে। এই সমস্যাটি কয়েকটি নতুন গবেষণা ভাষাগুলি, যেমন এফ * ( http://www.fstar-lang.org/tutorial/ ) দ্বারা সমাধান করা হয়েছে । এই ভাষাটি টাইপ সিস্টেমের অনুরূপ একটি প্রভাব ব্যবস্থা তৈরি করে , যেখানে কোনও ফাংশন কেবল স্ট্যাটিকভাবে তার প্রকারটিই ঘোষণা করে না, এর প্রভাবগুলিও। এইভাবে, ফাংশনটির কলকারীরা সচেতন হন যে ফাংশনটি কল করার সময় রাষ্ট্রীয় পরিবর্তন ঘটতে পারে এবং এর প্রভাবটি তার কলকারীদের কাছে প্রচারিত হয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.