Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NSNotificationCenter with blocks considered harmful

sealedabstract.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: NSNotificationCenter with blocks considered harmful

#31

Post by nielsbot »

jheriko wrote: post #14

I consider the whole of Objective-C harmful. It lives only in the 'platform' layer of my code. Grudgingly because Apple enforce it. It could be worse... they could have pulled a Google and used Java - then held back the tools they develop e.g. the Java VM because they are 'dangerous' and suggest that using native code is 'bad' if it is just for performance or cross-platform reasons. At least the interoperability with…

Are you saying you'd rather write apps in C++? I don't think the tradeoff is worth it.

Re: NSNotificationCenter with blocks considered harmful

#32

Post by ddustin »

pjungwir wrote: post #26

The book Programming iOS 6 by Matt Neuburg recommends the "weak-strong dance" for this, like so (p. 326): __weak MyClass* wself = self; self->observer = [[NSNotificationCenter defaultCenter] addObserverForName:@"heyho" object:nil queue:nil usingBlock:^(NSNotification *n) { MyClass *sself = wself; if (sself) { NSLog(@"%@", sself); } }]; Do other people agree this fixes the problem? Also, it's my understanding closures…

This is the correct way to access ivars. Though it makes a lot of indents so I usually do a return. I also use __strong to be explicit to the reader.

__strong MyClass *strongSelf = weakSelf;

if(!strongSelf) return;

... Rest of block

It's also worth noting calling functions on weakSelf can in turn access ivars. Getting a strong reference to self solves both the issues. NSLog calls [self description] in your example.

Re: NSNotificationCenter with blocks considered harmful

#33

Post by [deleted] »

pjungwir wrote: post #26

The book Programming iOS 6 by Matt Neuburg recommends the "weak-strong dance" for this, like so (p. 326): __weak MyClass* wself = self; self->observer = [[NSNotificationCenter defaultCenter] addObserverForName:@"heyho" object:nil queue:nil usingBlock:^(NSNotification *n) { MyClass *sself = wself; if (sself) { NSLog(@"%@", sself); } }]; Do other people agree this fixes the problem? Also, it's my understanding closures…

[deleted]

Re: NSNotificationCenter with blocks considered harmful

#35

Post by seandougall »

chc wrote: post #30
matwood wrote: post #20

Earlier quoted context omitted.

Apple's sample code is terrible. I've always assumed it is written by interns because it is generally bug ridden and often not the right way to do something.

Do you mean the code examples in articles or the projects that you can download? Because I haven't looked at their downloadable samples in quite some time, but their docs always seem alright to me.

Both, in my experience. The downloadable code is usually a rush job and has all sorts of sloppiness and missed edge cases. The code in the docs is usually cleaner (because it's just excerpts), but doesn't always get updated when APIs change.

Re: NSNotificationCenter with blocks considered harmful

#36

Post by jibbit »

Strilanc wrote: post #24

There are three related mistakes contributing to this bug: 1. The test is depending on dealloc being done eagerly. 2. The Attempt class puts unsubscribe code in its dealloc method. 3. The Attempt class does not force callers to control its lifetime. I'll go into more depth on these. 1. Cleanup is often deferred. Dealloc may only run AFTER the test instead of DURING the loop (e.g. I think NSArray defers releasing its…

There is no bug here. Just a very bad example.

Re: NSNotificationCenter with blocks considered harmful

#37

Post by matwood »

chc wrote: post #30
matwood wrote: post #20

Earlier quoted context omitted.

Apple's sample code is terrible. I've always assumed it is written by interns because it is generally bug ridden and often not the right way to do something.

Do you mean the code examples in articles or the projects that you can download? Because I haven't looked at their downloadable samples in quite some time, but their docs always seem alright to me.

The code samples are just bad and many are very outdated. I generally just read the header comments now and hit SO if I need more.

Re: NSNotificationCenter with blocks considered harmful

#38

Post by jheriko »

nielsbot wrote: post #31
jheriko wrote: post #14

I consider the whole of Objective-C harmful. It lives only in the 'platform' layer of my code. Grudgingly because Apple enforce it. It could be worse... they could have pulled a Google and used Java - then held back the tools they develop e.g. the Java VM because they are 'dangerous' and suggest that using native code is 'bad' if it is just for performance or cross-platform reasons. At least the interoperability with…

Are you saying you'd rather write apps in C++? I don't think the tradeoff is worth it.

yes, basically. i don't like paying the cost at runtime for a lot of things... NSArray is very useful for instance, but I can't use it for any serious amount of data I want to process in a frame. this comes down to the design of the language implementation not caring about performance. its not so much a tradeoff as 'for performance reasons I can not use Objective-C'

i also don't like the ref counting. when given a choice i would rather do my own allocations.

Re: NSNotificationCenter with blocks considered harmful

#39

Post by jheriko »

chrisdevereux wrote: post #29
jheriko wrote: post #28

Earlier quoted context omitted.

Any explanation for the downvotes? I concede the value of rapid application development, but objective-c itself doesn't provide this at all - rather the libraries like UIKit or Cocoa coupled with the Xcode development environment do this. Objective-C is measurably bad for my code. I have reams of data to support this... and its all trivially reproducable.

I didn't downvote you, but you directed a lot of loosely-connected negative assertions at a single target without really backing any of them up. Whatever you intended, it came across as a bit of a rant.

when i mention the slowness of the message mechanism this is both by design of Objective-C (for runtime features) and very measurable. this is why, for example, NSArray becomes prohibitively slow when you want to iterate across 1000s of members.

Objective-C is nice, but its slow by design, and this rules it out in a concrete way for a lot of the work I've done.

Its sad when optimisation comes down to 'knowing better than the compiler' only because of language constraints. (even C has this problem with struct layout for example - its just prevalent when using Objective-C/Cocoa (Touch))

Post reply on HN