Hacker News new | ask | show | jobs
by antimagic 4587 days ago
Not to mention that using 'self' in a block is just not a good idea to start with. Conceptually a block is not a method, so it doesn't have a well-defined self. Instead we are relying on the lexical scope capturing of blocks. The thing is, the documentation is very clear about what happens when you access self in a block[1]: "When a block is copied, it creates strong references to object variables used within the block. If you use a block within the implementation of a method:

    If you access an instance variable by reference, a strong reference is made to self;

    If you access an instance variable by value, a strong reference is made to the variable."
Right. So if you use self or an instance variable, you've just created a strong reference. In Drew's example, as he is relying on the object going out of scope, that will still leave the reference held by the block, which is itself held by the NotificationCenter. As with all reference cycles, the way out is to get the NotificationCenter to stop observing that notification, or as the Apple documentation says, use a local variable that takes the value of self, and use that local variable inside the block. This is the solution that Drew presents as Attempt6, but quite frankly would have been my very first attempt when the test failed. The stuff about __block is a red-herring, and from the documentation goes in the opposite direction that Drew wants, forcing a strong reference rather than removing it.

Drew also gets bitten by NSAssert using self. I would suggest that it is NSAssert that is doing something dodgy here - it's trying to have an implicit self, as though it was a method, when it most definately isn't a method - and Drew just got bitten by the impedence mismatch. Macros - just say no.