mikeash.com pyblog/friday-qa-2011-07-08-lets-build-nsnotificationcenter.html comments

Daniel - 2011-09-24 09:52:15

Sat, 24 Sep 2011 09:52:15 GMT

Yet again, another great Q&A!

I especially liked returning the removalBlock as the token from addObserverForName:… — very simple and elegant solution!

Steven - 2011-07-11 04:17:34

Mon, 11 Jul 2011 04:17:34 GMT

As a topic for next time, how might one implement mocks/stubs in ObjC like RSpec has?

mikeash - 2011-07-09 00:14:10

Sat, 09 Jul 2011 00:14:10 GMT

You're right that that scenario would lead to endless recursion. I'll defer to an old article of mine for further info:

http://mikeash.com/pyblog/the-how-and-why-of-cocoa-initializers.html

That probably says that you're right and I'm wrong here.

Regarding if(!a || !b), it's not redundant. Technically it doesn't need to check a, as the isEqual: check will return NO if a is nil, although a separate check is slightly faster (and more explicit) for that case. The real importance is for b, as the result of sending nil to isEqual: is not, as far as I know, well defined and could potentially throw an exception or crash.

Colin - 2011-07-08 21:52:14

Fri, 08 Jul 2011 21:52:14 GMT

I know it's just an academic case, but if you'd subclass _MANotificationCenterDictionaryKey overriding init and calling _initWithName:object:from there this could lead to endless recursion, couldn't it?

Another remark: Isn't the else if(!a || !b) branch of the Equal function redundant?

mikeash - 2011-07-08 21:01:33

Fri, 08 Jul 2011 21:01:33 GMT

Allan: Or use a zeroing weak reference! Yes, notifications and blocks get kind of irritating when not using garbage collection.

Colin: Just a habit not to use super unless it's necessary. Since init isn't overridden, it's not necessary here.

Colin - 2011-07-08 20:41:42

Fri, 08 Jul 2011 20:41:42 GMT

In the implementation of

- (id)_initWithName: (NSString *)name object: (id)obj

for

_MANotificationCenterDictionaryKey

is there a reason for writing

if((self = [self init]))

instead of

if((self = [super init]))

?

Allan - 2011-07-08 19:34:22

Fri, 08 Jul 2011 19:34:22 GMT

I think it would be worth adding to the caveats section that block based notification handling is tricky from a memory management point of view. If a block observing a notification references an object, then the object is retained by the block, and the block is retained by the notification center. Many times, the logical place to unsubscribe from a notification is in the dealloc method of an object, but that won't work if a notification observing block retains the object that would unregister during deallocation. When creating notification observing blocks, its often a good practice to make sure you're using a __block typed pointer to self instead of self itself.