एक संपत्ति मौजूद होने पर ivar का उद्देश्य क्या है?

Question

निम्नलिखित संकलन और न ही रनटाइम पर कोई name ivar के बारे में शिकायत नहीं करता है। तो ivar और@property/@synthesize देखने के लिए यह इतना आम क्यों है?

@interface PropTest : NSObject 
{ 
} 
@property (retain) NSString *name; 
@end 

@implementation PropTest 
@synthesize name; 
@end 

int main (int argc, const char * argv[]) { 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; 
    PropTest *p = [[PropTest new] autorelease]; 
    p.name = @"Hello, World!"; 
    NSLog(@"%@",p.name); 
    [pool drain]; 
    return 0; 
} 

इस कोड को प्रिंट

Hello, World! 

वास्तव में, अगर मैं का उपयोग p->name, मैं एक चेतावनी मिलती है:

warning: instance variable 'name' is @private; this will be a hard error in the future 

जो दर्शाता है कि इवर अगर एक नहीं करता है 'मेरे लिए बनाई गई है टी मौजूद नहीं है।

यदि यह सच है, तो ivar मैन्युअल रूप से बनाने का मुद्दा क्या है (स्पष्ट रूप से अनदेखा कर रहा है कि कभी-कभी g/setter accessor का उपयोग करने के वैध कारण नहीं हैं)?

या अलग से पूछा, क्या मुझे केवल किसी संपत्ति के लिए एक ivar बनाना चाहिए जब मुझे एक्सेसर्स को बाईपास करना होगा?

Answer 1

संश्लेषित ivars (मैन्युअल रूप से ivars घोषित करने की क्षमता) नए उद्देश्य-सी रनटाइम की एक विशेषता है, जो अभी भी सभी प्रणालियों पर उपयोग नहीं किया जा रहा है। 32-बिट मैक के लिए (और, हाल ही में, आईफोन सिम्युलेटर तक), आपको मैन्युअल रूप से इवर्स घोषित करना होगा। यदि आप केवल नए रनटाइम के साथ सिस्टम को लक्षित कर रहे हैं, तो मैन्युअल रूप से इवर्स घोषित करने का कोई कारण नहीं है।

Answer 2

ईमान का जवाब कुल मिलाकर सही है, लेकिन अभी भी नए रनटाइम में भी इवर घोषित करने का एक कारण है: ऐप्पल इनिट और डेलोक विधियों में संश्लेषित एक्सेसर्स को हतोत्साहित करता है। अनिवार्य रूप से, गेटर्स और सेटर्स को एक चर सेट करने के अलावा साइड इफेक्ट्स होने की अनुमति है। विशेष रूप से, वे केवीओ अधिसूचनाओं को ट्रिगर कर सकते हैं। एक इवर से बात करने के लिए, आप बस release भेज सकते हैं और इसके साथ किया जा सकता है। लेकिन अगर आपके पास एक संपत्ति है, तो आपकी एकमात्र पसंद यह तय करना है और उम्मीद है कि आप किसी भी दुर्भाग्यपूर्ण बातचीत से बचें।

मुझे यकीन नहीं है कि यह ईमानदार होने के लिए अभ्यास में कितनी बड़ी समस्या है। मैंने बस अंधविश्वास से इसे टाला है, भले ही मैं गुप्त रूप से संदेह करता हूं कि इससे ज्यादातर मामलों में समस्या आती है। लेकिन ऐप्पल दस्तावेज़ों में इसका एक मुद्दा बना देता है, इसलिए मुझे लगता है कि चिंतित होने का कोई कारण है।

Answer 3

दो नहीं-तो-अच्छा बल्कि आवश्यक यकीन है कि गुण बनाने के लिए कारणों ivars द्वारा समर्थित किया गया है:

1. किसी कारण XCode डिबगर गुण इसी ivars स्पष्ट नहीं है कि प्रदर्शित नहीं करता है के लिए की घोषणा की।
2. मुझे ऐसा लगता है कि कुछ एक इवर बिना @property का उपयोग अन्य ivars छिपा कर सकते हैं, संकलन त्रुटियों में जिसके परिणामस्वरूप परिस्थितियों में (देखें Why does a subclass @property with no corresponding ivar hide superclass ivars?)

जब तक मैं लाठी के एक जोड़े के गलत समाप्त होता है यहाँ मिल गया है , मुझे लगता है कि स्पष्ट इवर के बिना @property का उपयोग सुविधा से जरूरी परेशानियों का कारण बन सकता है।