Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Initializing a property, dot notation

Tags:

Is it a bad idea to use the dot notation to initialize retain properties to nil in my init methods?

With any ordinary property like this:

@property (nonatomic, retain) id foo; 

Say in my init method I set self.foo = nil. The synthesized method first releases or autoreleases foo (not exactly sure of the underlying impementation). Is foo guaranted to be nil before the first setter or getter call? Or would it point to random garbage unless I explicitly set foo = nil without the dot notation?

like image 939
Morrowless Avatar asked May 09 '11 04:05

Morrowless


People also ask

How do you write dot notation?

Dot notation is one way to access a property of an object. To use dot notation, write the name of the object, followed by a dot (.), followed by the name of the property. Example: var cat = { name: 'Moo', age: 5, }; console.

What is dot notation in JavaScript?

JavaScript provides two notations for accessing object properties. The first, and most common, is known as dot notation. Under dot notation, a property is accessed by giving the host object's name, followed by a period (or dot), followed by the property name.

What is dot notation in TypeScript?

The question mark dot (?.) syntax is called optional chaining in TypeScript and is like using dot notation to access a nested property of an object, but instead of causing an error if the reference is nullish, it short-circuits returning undefined .

Which notation is used to access the the instance name and the property references that property?

Property accessors provide access to an object's properties by using the dot notation or the bracket notation.


1 Answers

Is it a bad idea to use the dot notation to initialize retain properties to nil in my init methods?

Yes, it is a bad idea.

1) The object has already been zeroed in the alloc+init sequence, so it is not necessary to assign it nil. In other words, this call is useless unless you have side effects in your accessors (side effects in accessors should also be avoided at this stage).

2) You should not message self with methods which are overridden while in partially constructed states (e.g. init and dealloc).

Is there a reason for #2? I often do self.array = [NSMutableArray array]; in my init methods.

The reason is that your object should not be interested in the class interface's behavior during partially constructed states (init..., dealloc, finalize, and many copyWithZone: implementations). your class should be interested in initializing properly (as in init...) and cleaning up after itself including its members (as in dealloc) without introducing side-effects.

consider this example, which you can build as a Foundation tool for OS X:

#import <Foundation/Foundation.h>  enum { UseItTheRightWay = true -OR- false };  @interface MONObjectA : NSObject {     NSMutableArray * array; }  @property (nonatomic, retain) NSArray * array;  @end  @implementation MONObjectA  @synthesize array;  - (id)init {     self = [super init];     if (0 != self) {         NSLog(@"%s, %@",__PRETTY_FUNCTION__, self);         if (UseItTheRightWay) {             array = [NSMutableArray new];         }         else {             self.array = [NSMutableArray array];         }     }     return self; }  - (void)dealloc {     NSLog(@"%s, %@",__PRETTY_FUNCTION__, self);     if (UseItTheRightWay) {         [array release], array = nil;     }     else {         self.array = nil;     }     [super dealloc]; }  @end  @interface MONObjectB : MONObjectA {     NSMutableSet * set; }  @end  @implementation MONObjectB  - (id)init {     self = [super init];     if (0 != self) {         NSLog(@"%s, %@",__PRETTY_FUNCTION__, self);         set = [NSMutableSet new];     }     return self; }  - (void)dealloc {     NSLog(@"%s, %@",__PRETTY_FUNCTION__, self);     [set release], set = nil;     [super dealloc]; }  - (void)setArray:(NSArray *)arg {     NSLog(@"%s, %@",__PRETTY_FUNCTION__, self);     NSMutableSet * tmp = arg ? [[NSMutableSet alloc] initWithArray:arg] : nil;     [super setArray:arg];     [set release];     set = tmp; }  @end  int main (int argc, const char * argv[]) {     NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];      [[MONObjectB new] release];      /* the tool must be named 'Props' for this to work as expected, or you can just change 'Props' to the executable's name */     system("leaks Props");      [pool drain];     return 0; } 

The main switch to toggle behavior in this test is UseItTheRightWay.

If UseItTheRightWay is true, we are given the result:

2011-05-09 01:52:11.175 Props[45138:a0f] -[MONObjectA init], <MONObjectB: 0x10010c750> 2011-05-09 01:52:11.177 Props[45138:a0f] -[MONObjectB init], <MONObjectB: 0x10010c750> 2011-05-09 01:52:11.179 Props[45138:a0f] -[MONObjectB dealloc], <MONObjectB: 0x10010c750> 2011-05-09 01:52:11.179 Props[45138:a0f] -[MONObjectA dealloc], <MONObjectB: 0x10010c750> leaks Report Version:  2.0 Process:         Props [45138] < --- snip --- >         Process 45138: 1581 nodes malloced for 296 KB Process 45138: 0 leaks for 0 total leaked bytes. 

And if UseItTheRightWay is false, we are given the result:

2011-05-09 01:55:51.611 Props[45206:a0f] -[MONObjectA init], <MONObjectB: 0x10010c750> 2011-05-09 01:55:51.614 Props[45206:a0f] -[MONObjectB setArray:], <MONObjectB: 0x10010c750> 2011-05-09 01:55:51.615 Props[45206:a0f] -[MONObjectB init], <MONObjectB: 0x10010c750> 2011-05-09 01:55:51.617 Props[45206:a0f] -[MONObjectB dealloc], <MONObjectB: 0x10010c750> 2011-05-09 01:55:51.618 Props[45206:a0f] -[MONObjectA dealloc], <MONObjectB: 0x10010c750> 2011-05-09 01:55:51.618 Props[45206:a0f] -[MONObjectB setArray:], <MONObjectB: 0x10010c750> leaks Report Version:  2.0 Process:         Props [45206]  < --- snip --- >     Process 45206: 1585 nodes malloced for 297 KB Process 45206: 1 leak for 48 total leaked bytes. Leak: 0x100110970  size=48  zone: DefaultMallocZone_0x100005000 instance of 'NSCFSet', type ObjC, implemented in Foundation      0x70294ff8 0x00007fff 0x00001080 0x00000001     .O)p............     0x00000001 0x00000000 0x00000000 0x00010000     ................     0x707612a8 0x00007fff 0x00000000 0x00000000     ..vp............ 

Problem #1

This example's obvious failure is the leak, introduced in dealloc.

Problem #2

The second thing that will bite you is subtler:

-[MONObjectA init] -[MONObjectB setArray:] -[MONObjectB init] 

What's this??? -[MONObjectB setArray:] is called before -[MONObjectB init]? That means that MONObjectB's implementation is used before -[MONObjectB init], and even before -[MONObjectA init] has exited. That's no good =\

Nontrivial designs will just produce a bunch of undesirable side effects, weird behavior, leaks, and so on. Complex designs will fail in very obvious, and very subtle ways which can be very difficult to track down. it's best to avoid maintenance headaches over such trivial written differences, and to write classes the proper way from the start (even though you could get away doing this for quite some time, without obvious side effects).

like image 160
justin Avatar answered Nov 07 '22 11:11

justin