কেন "স্পষ্টতভাবে মোড়ানো বিকল্পগুলি" তৈরি করবেন, যেহেতু এর থেকে বোঝা যায় যে আপনি জানেন যে এর কোনও মূল্য আছে?

Question

আপনি কেন কেবল "নিয়মিত পরিবর্তনশীল বা ধ্রুবক তৈরি করে বনাম" অন্তর্নিহিত wচ্ছিক createচ্ছিক "তৈরি করবেন? যদি আপনি জানেন যে এটি সফলভাবে মোড়ানো যায় তবে প্রথমে anচ্ছিক কেন তৈরি করবেন? উদাহরণস্বরূপ, এটি কেন:

let someString: String! = "this is the string"

এর চেয়ে আরও কার্যকর হতে চলেছে:

let someString: String = "this is the string"

যদি "বিকল্পগুলি নির্দেশ করে যে একটি ধ্রুবক বা ভেরিয়েবলের 'কোনও মূল্য নেই'" অনুমোদিত, তবে "কখনও কখনও কোনও প্রোগ্রামের কাঠামো থেকে স্পষ্ট হয় যে alwaysচ্ছিকের সর্বদা একটি মান সেই মানটি প্রথম সেট হওয়ার পরে থাকবে", এর বিন্দুটি কী? এটি প্রথম স্থানে একটি makingচ্ছিক করা? আপনি যদি জানেন যে anচ্ছিকের সর্বদা একটি মান থাকে, তবে এটি কী optionচ্ছিক হয় না?

Answer 1

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

(সম্পাদনা) যদিও পরিষ্কার হতে হবে: নিয়মিত বিকল্প প্রায় সর্বদা পছন্দনীয়।

Answer 2

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

যখন একটি সুস্পষ্টভাবে মোড়কযুক্ত Useচ্ছিক ব্যবহার করতে হয়

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

1. একটি ধ্রুবক যা আরম্ভের সময় সংজ্ঞায়িত করা যায় না

প্রতিটি সদস্য ধ্রুবকের অবশ্যই সময় সূচনা সম্পন্ন হওয়ার পরে একটি মান থাকতে হবে। কখনও কখনও, প্রারম্ভকালীন সময়ে একটি ধ্রুবককে তার সঠিক মান দিয়ে আরম্ভ করা যায় না, তবে এটি অ্যাক্সেস হওয়ার আগে একটি মান থাকার গ্যারান্টি দেওয়া যেতে পারে।

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

এর একটি দুর্দান্ত উদাহরণ হ'ল যখন সদস্যের ভেরিয়েবলটি কোনও ইউআইভিউ সাবক্লাসে ভিউ লোড না হওয়া পর্যন্ত শুরু করা যায় না:

class MyView: UIView {
    @IBOutlet var button: UIButton!
    var buttonOriginalWidth: CGFloat!

    override func awakeFromNib() {
        self.buttonOriginalWidth = self.button.frame.size.width
    }
}

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

২. যখন আপনার অ্যাপ্লিকেশন কোনও পরিবর্তনশীল জীব থেকে পুনরুদ্ধার করতে পারে না nil

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

যখন একটি স্পষ্টভাবে মোড়কযুক্ত Useচ্ছিক ব্যবহার করবেন না

1. অলস গণনা সদস্য ভেরিয়েবল

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

class FileSystemItem {
}

class Directory : FileSystemItem {
    lazy var contents : [FileSystemItem] = {
        var loadedContents = [FileSystemItem]()
        // load contents and append to loadedContents
        return loadedContents
    }()
}

এখন, সদস্য ভেরিয়েবলটি contentsপ্রথমবার অ্যাক্সেস না করা পর্যন্ত শুরু করা হয় না। এটি প্রাথমিক মান গণনা করার আগে শ্রেণিকে সঠিক অবস্থায় প্রবেশের সুযোগ দেয়।

দ্রষ্টব্য: এটি উপরের থেকে # 1 টি বিপরীত বলে মনে হতে পারে। তবে একটি গুরুত্বপূর্ণ পার্থক্য করা উচিত। buttonOriginalWidthউপরে পরিবর্তন করার আগে সম্পত্তি অ্যাক্সেস করা হয় বোতাম প্রস্থ বিরত রাখার জন্য viewDidLoad সময় সেট করতে হবে।

2. অন্য কোথাও

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

Comments

এই উত্তরটি বিটা 5 এর জন্য আপডেট করা উচিত You আপনি আর ব্যবহার করতে পারবেন না if someOptional।

— সান্তা ক্লজ

@ সান্টাক্লাউস hasValueঠিক ptionচ্ছিকভাবে সংজ্ঞায়িত করা হয়েছে। আমি hasValueযারা এর শব্দার্থবিজ্ঞান পছন্দ != nil। আমি মনে করি যে এটি নতুন প্রগ্রেমার যারা nilঅন্য ভাষায় ব্যবহার করেন নি তাদের পক্ষে এটি অনেক বেশি বোধগম্য । hasValueএর চেয়ে অনেক বেশি যৌক্তিক nil।

— অগস্ট

দেখে মনে হচ্ছে hasValueএটি বিটা from থেকে টানা হয়েছিল it অ্যাশ এটি ফিরিয়ে দিয়েছে যদিও ... github.com/AshFurrow/hasValue

— ক্রিস ওয়াগনার

@ নিউক্যাক্ট ওবজেসি আরম্ভকারীদের রিটার্ন প্রকারের বিষয়ে, এটি আরও অন্তর্নিহিত licitচ্ছিকভাবে অন্তর্ভুক্ত ptionচ্ছিক। একটি "অ-optionচ্ছিক" ব্যবহারের জন্য আপনি যে আচরণটি বর্ণনা করেছেন তা হ'ল প্রকৃতভাবে মোড়কযুক্ত ptionচ্ছিকভাবে করা (অ্যাক্সেস না হওয়া পর্যন্ত ব্যর্থ হয় না)। জোর করে আন-র্যাপিং করে প্রোগ্রামটিকে ব্যর্থ হওয়ার অনুমতি দেওয়ার বিষয়ে, আমি একমত যে একটি অ-alচ্ছিক ব্যবহার পছন্দ করা হয়, তবে এটি সর্বদা সম্ভব হয় না।

— ড্র্যাগ করুন

@ কনফিলে নং যাই হোক না কেন, এটি পয়েন্টার হিসাবে অবজেক্টিভ-সিতে উপস্থিত হতে চলেছে (যদি এটি optionচ্ছিক, অন্তর্নিহিতভাবে আবদ্ধ বা অ-alচ্ছিক ছিল)।

— চালিত করুন

Answer 3

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

উদাহরণ স্বরূপ:

// These classes are buddies that never go anywhere without each other
class B {
    var name : String
    weak var myBuddyA : A!
    init(name : String) {
        self.name = name
    }
}

class A {
    var name : String
    var myBuddyB : B
    init(name : String) {
        self.name = name
        myBuddyB = B(name:"\(name)'s buddy B")
        myBuddyB.myBuddyA = self
    }
}

var a = A(name:"Big A")
println(a.myBuddyB.name)   // prints "Big A's buddy B"

যে কোনও Bউদাহরণের সর্বদা একটি বৈধ myBuddyAরেফারেন্স থাকতে হবে, তাই আমরা ব্যবহারকারীটিকে এটি বিকল্প হিসাবে বিবেচনা করতে চাই না, তবে আমাদের এটি optionচ্ছিক হওয়া দরকার যাতে আমাদের উল্লেখ করার Bআগে আমরা একটি নির্মাণ করতে পারি A।

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

Comments

আমি মনে করি তারা এই ভাষার বৈশিষ্ট্য তৈরির একটি কারণ হ'ল@IBOutlet

— জিয়ারো

"HOWEVER" ক্যাভিয়েটের জন্য +1। এটি সর্বদা সত্য নাও হতে পারে তবে এটি অবশ্যই খুঁজে বের করার মতো কিছু।

— জেএমডি

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

— ড্র্যাগ্যাগ করুন

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

— ড্র্যাগ করুন

@ দ্রুয়াগ: আপনি ঠিক বলেছেন - ধরে রাখার চক্রটি সরিয়ে ফেলতে আমি উত্তরটি সম্পাদনা করেছি। আমি ব্যাকরিফারেন্সকে দুর্বল করার উদ্দেশ্যেছিলাম কিন্তু আমার ধারণা এটি আমার মন কেড়ে নিয়েছে।

— n8 গ্রে

Answer 4

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

দ্য বেসিক্স অধ্যায়ের সুইফট বইটি বিভাগে সুস্পষ্টভাবে মোড়কযুক্ত বিকল্পগুলি বলে:

সুস্পষ্টভাবে মোড়কযুক্ত বিকল্পগুলি কার্যকর হয় যখন .চ্ছিক প্রথম সংজ্ঞায়িত হওয়ার পরে অবিলম্বে তার valueচ্ছিক মানটির উপস্থিতি নিশ্চিত হয়ে যায় এবং তারপরে অবশ্যই প্রতিটি বিন্দুতে উপস্থিত থাকতে পারে umed অবাঞ্ছিত রেফারেন্সে বর্ণিত এবং স্পষ্টতভাবে মোড়কযুক্ত Oচ্ছিক বৈশিষ্ট্যগুলিতে বর্ণিত হিসাবে সুইফ্টে স্পষ্টত মোড়কযুক্ত বিকল্পগুলির প্রাথমিক ব্যবহার শ্রেণি শুরুর সময় ।
…
আপনি যখনই এটি ব্যবহার করা হয় তখন automaticallyচ্ছিকভাবে স্বয়ংক্রিয়ভাবে মোড়ক হওয়ার জন্য অনুমতি দেওয়ার হিসাবে আপনি একটি স্পষ্টভাবে অনাবৃত optionচ্ছিকের কথা ভাবতে পারেন। প্রতিবার আপনি যখন এটি ব্যবহার করবেন তখন alচ্ছিক নামের পরে একটি বিস্ময় চিহ্নটি রাখার পরিবর্তে আপনি যখন এটি ঘোষণা করবেন তখন আপনি alচ্ছিকর প্রকারের পরে একটি বিস্ময়বোধক চিহ্ন রাখবেন।

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

সুইফট বইয়ের উপরের অংশটি স্বয়ংক্রিয় রেফারেন্স গণনা অধ্যায়েও বোঝায় :

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

সূচনাচক্রটি সম্পূর্ণ হওয়ার পরে এটি কোনও রেফারেন্স চক্র এড়িয়ে যাওয়ার পরে, উভয় বৈশিষ্ট্যই সরাসরি (optionচ্ছিক আনারপ্যাটিং ছাড়াই) অ্যাক্সেস করতে সক্ষম করে।

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

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

সুইচ উইথ কোকো এবং অবজেক্টিভ-সি, ব্যবহার বিভাগ থেকে শূন্যের সাথে কাজ করা :

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

কিছু ক্ষেত্রে, আপনি একেবারে নিশ্চিত হতে পারেন যে কোনও উদ্দেশ্য-সি পদ্ধতি বা সম্পত্তি কখনই কোনও nilবস্তুর রেফারেন্স দেয় না। এই বিশেষ দৃশ্যে জিনিসগুলির সাথে কাজ করার জন্য আরও সুবিধাজনক করে তোলার জন্য, সুইফট অবজেক্টের ধরণগুলি সুস্পষ্টভাবে মোড়কযুক্ত বিকল্প হিসাবে আমদানি করে । সুস্পষ্টভাবে মোড়কযুক্ত alচ্ছিক typesচ্ছিক প্রকারগুলিতে alচ্ছিক ধরণের সমস্ত সুরক্ষা বৈশিষ্ট্য অন্তর্ভুক্ত রয়েছে। এছাড়াও, আপনি পরীক্ষা না করে সরাসরি মানটি অ্যাক্সেস করতে পারেনnilবা নিজেই এটি মোড়ক করা। যখন আপনি নিরাপদে প্রথমে মোড়ক ছাড়াই এই জাতীয় optionচ্ছিক প্রকারের মানটি অ্যাক্সেস করেন, তখন মানটি অনুপস্থিত .চ্ছিকভাবে unচ্ছিকভাবে পরীক্ষা করে। মানটি অনুপস্থিত থাকলে একটি রানটাইম ত্রুটি ঘটে। ফলস্বরূপ, আপনার অবশ্যই সর্বদা একটি অন্তর্নিহিত wচ্ছিক alচ্ছিক নিজেকে চেক করা ও মোড়ক করা উচিত, যদি না আপনি নিশ্চিত হন যে মানটি অনুপস্থিত cannot

... এবং এখানে অতিক্রম করা

Comments

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

— হেয়ারগামি_মাস্টার

@ হায়ারগামি_মাস্টার আমি নিজের তালিকাটি একটি তালিকা এবং কংক্রিটের উদাহরণগুলির সাথে যুক্ত করেছি

— ড্র্যাগ্যাগ

Answer 5

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

আমি এখনও অবধি দেখা সেরা কেসটি হ'ল সেটআপ যা অবজেক্ট ইনিশিয়ালের পরে ঘটে, তারপরে সেই সেটআপটি অনুসরণ করার জন্য "গ্যারান্টিযুক্ত" ব্যবহার করা হয়, যেমন একটি ভিউ কন্ট্রোলারে:

class MyViewController: UIViewController {

    var screenSize: CGSize?

    override func viewDidLoad {
        super.viewDidLoad()
        screenSize = view.frame.size
    }

    @IBAction printSize(sender: UIButton) {
        println("Screen size: \(screenSize!)")
    }
}

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

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

Comments

কেন কেবল স্ক্রিজ সাইজকে সিজিসিজে (উচ্চতা: 0, প্রস্থ: 0) আরম্ভ করবেন না এবং প্রতিবার আপনি যখন অ্যাক্সেস করবেন তখন ভেরিয়েবলটি চিৎকার করার সমস্যাটি সংরক্ষণ করবেন না?

— মার্টিন গর্ডন

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

— রিকটার

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

— ওয়েইন ট্যানার

আমি মনে করি আপনি ওপি-র প্রশ্নটি ভুল বুঝেছেন। ওপি বিকল্পগুলির জন্য সাধারণ ক্ষেত্রে জিজ্ঞাসা করছে না, বরং বিশেষভাবে স্পষ্টতভাবে মোড়কযুক্ত বিকল্পগুলির প্রয়োজন / ব্যবহার সম্পর্কে (অর্থাত না let foo? = 42, বরং let foo! = 42)) এটি এটিকে সম্বোধন করে না। (এটি বিকল্পগুলির সম্পর্কে প্রাসঙ্গিক উত্তর হতে পারে, মনে রাখবেন, তবে কোনও পৃথক / সম্পর্কিত প্রাণী যা স্পষ্টতই মোড়কানো বিকল্পগুলি সম্পর্কে নয়))

— জেএমডি

Answer 6

অ্যাপল দ্য সুইফ্ট প্রোগ্রামিং ল্যাঙ্গুয়েজে -> স্বয়ংক্রিয় রেফারেন্স গণনা -> শ্রেণীর উদাহরণগুলির মধ্যে শক্তিশালী রেফারেন্স চক্রগুলি সমাধান করে -> অযৌক্তিক রেফারেন্স এবং সুস্পষ্টভাবে মোড়কযুক্ত ptionচ্ছিক বৈশিষ্ট্যগুলিতে একটি দুর্দান্ত উদাহরণ দেয়

class Country {
    let name: String
    var capitalCity: City! // Apple finally correct this line until 2.0 Prerelease (let -> var)
    init(name: String, capitalName: String) {
        self.name = name
        self.capitalCity = City(name: capitalName, country: self)
    }
}

class City {
    let name: String
    unowned let country: Country
    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

ইনিশিয়ালাইজারের জন্য Cityইনিশিয়ালাইজারের জন্য কল করা হয় Country। যাইহোক, দ্বি-পর্বের সূচনাতে বর্ণিত হিসাবে কোনও নতুন দৃষ্টান্ত পুরোপুরি আরম্ভ না হওয়া পর্যন্ত এর জন্য ইনিশিয়ালাইজার প্রাথমিক পর্যায়ে Countryযেতে পারে না ।selfCityCountry

এই প্রয়োজনীয়তাটি মোকাবেলার জন্য, আপনি একটি স্পষ্টতভাবে মোড়কযুক্ত raচ্ছিক সম্পত্তি হিসাবে capitalCityসম্পত্তি Countryহিসাবে ঘোষণা করেন ।

Comments

এই উত্তরে উল্লিখিত টিউটোরিয়ালটি এখানে ।

— ফ্র্যাঙ্কলিন ইউ

Answer 7

অন্তর্নিহিত বিকল্পগুলির যৌক্তিকতা প্রথমে জোর করে আন-র্যাপিংয়ের যুক্তিটি দেখে বোঝানো সহজ।

বাধ্যতামূলকভাবে একটি ofচ্ছিক (অন্তর্নিহিত বা না) আন-র্যাপিং ব্যবহার করে! অপারেটর, এর অর্থ হল আপনি নিশ্চিত যে আপনার কোডটিতে কোনও বাগ নেই এবং alচ্ছিকের ইতিমধ্যে একটি মান রয়েছে যেখানে এটি মোড়ানো হয়। ছাড়া ! অপারেটর, আপনি সম্ভবত একটি alচ্ছিক বাঁধাই দিয়ে দৃ with়ভাবে দাবি করবেন:

 if let value = optionalWhichTotallyHasAValue {
     println("\(value)")
 } else {
     assert(false)
 }

যা হিসাবে ভাল না

println("\(value!)")

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

Comments

@ নিউওয়া্যাক্ট: আপনার কোডের মাধ্যমে সমস্ত সম্ভাব্য প্রবাহে নন-শূন্যপদ ডিএলোকেশনের মাধ্যমে প্যারেন্ট (ক্লাস / স্ট্রাক্ট) ইনিশিয়ালাইজেশনের কাছ থেকে অ-নীল নয়। ইন্টারফেস বিল্ডার ক্লাসিক উদাহরণ (তবে প্রচুর বিলম্বিত আরম্ভের ধরণ রয়েছে): যদি কোনও ক্লাস কেবল কখনও কোনও নিব থেকে ব্যবহৃত হয়, তবে আউটলেট ভেরিয়েবলগুলি সেট করা হবে না init(যা আপনি সম্ভবত বাস্তবায়নও করতে পারবেন না) তবে তারা ' পুনরায় / পরে সেট করা গ্যারান্টিযুক্ত । awakeFromNibviewDidLoad

— রিক্সার

Answer 8

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

//Optional string with a value
let optionalString: String? = "This is an optional String"

//Declaration of an Implicitly Unwrapped Optional String
let implicitlyUnwrappedOptionalString: String!

//Declaration of a non Optional String
let nonOptionalString: String

//Here you can catch the value of an optional
implicitlyUnwrappedOptionalString = optionalString

//Here you can't catch the value of an optional and this will cause an error
nonOptionalString = optionalString

সুতরাং এটি ব্যবহারের মধ্যে পার্থক্য

let someString : String! এবং let someString : String

Comments

এটি ওপি-র প্রশ্নের উত্তর দেয় না। ওপি জানে যে একটি স্পষ্টতভাবে মোড়ানো .চ্ছিক।

— ফ্র্যাংকলিন ইউ

Answer 9

আমি মনে করি Optionalএই নির্মাণের একটি খারাপ নাম যা প্রচুর প্রাথমিকের মানুষকে বিভ্রান্ত করে।

অন্যান্য ভাষা (উদাহরণস্বরূপ কোটলিন এবং সি #) শব্দটি ব্যবহার করে Nullableএবং এটি এটি বোঝা অনেক সহজ করে তোলে।

Nullableএর অর্থ আপনি এই ধরণের ভেরিয়েবলের নাল মান নির্ধারণ করতে পারেন। সুতরাং যদি এটি Nullable<SomeClassType>হয় তবে আপনি এটিতে নাল বরাদ্দ করতে পারেন, যদি এটি ঠিক হয় তবে SomeClassTypeআপনি পারবেন না। এটি ঠিক কিভাবে সুইফট কাজ করে।

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

বিটিডব্লিউ, আমি আপনাকে পরামর্শ দিচ্ছি যে এটি কোটলিন এবং সি # এর মতো অন্যান্য ভাষায় কীভাবে কাজ করে।

কোটলিনে এই বৈশিষ্ট্যটি ব্যাখ্যা করার জন্য এখানে একটি লিঙ্ক রয়েছে: https://kotlinlang.org/docs/references/null-safety.html

জাভা এবং স্কালার মতো অন্যান্য ভাষারও রয়েছে তবে সেগুলি সুইফটে Optionalভিন্ন ভিন্নভাবে কাজ করে Optional, কারণ জাভা এবং স্কালার প্রকারগুলি সমস্তই ডিফল্টরূপে নমনীয়।

সব মিলিয়ে আমি মনে করি এই বৈশিষ্ট্যটির নাম Nullableসুইফটে রাখা উচিত ছিল , না Optional...

Answer 10

Implicitly Unwrapped Optionalএটি একটি সিনট্যাকটিক চিনি যার জন্য Optionalকোনও প্রোগ্রামারকে একটি ভেরিয়েবল আন-আপ করতে বাধ্য করে না। এটি কোনও চলকটির জন্য ব্যবহার করা যেতে পারে যা চলাকালীন আরম্ভ করা যায় না two-phase initialization processএবং শিরোনামকে বোঝায় । এই পরিবর্তনশীল হিসাবে নিজেকে আচরণ করে অ শূন্য কিন্তু আসলে একটি হয় ঐচ্ছিক পরিবর্তনশীল। একটি ভাল উদাহরণ হ'ল - ইন্টারফেস বিল্ডারের আউটলেটগুলি

Optional সাধারণত ভাল হয়

var nonNil: String = ""
var optional: String?
var implicitlyUnwrappedOptional: String!

func foo() {
    //get a value
    nonNil.count
    optional?.count

    //Danderour - makes a force unwrapping which can throw a runtime error
    implicitlyUnwrappedOptional.count

    //assign to nil
//        nonNil = nil //Compile error - 'nil' cannot be assigned to type 'String'
    optional = nil
    implicitlyUnwrappedOptional = nil
}