Re: ARC, blocks, capture variables
Re: ARC, blocks, capture variables
- Subject: Re: ARC, blocks, capture variables
- From: Quincey Morris <email@hidden>
- Date: Mon, 28 Sep 2015 16:53:51 -0700
- Feedback-id: 167118m:167118agrif8a:167118sGY9JgRGVV:SMTPCORP
On Sep 28, 2015, at 15:20 , Scott Ribe <email@hidden> wrote:
>
> The essential problem was in the library design, not the calls. I was keeping self.authfun as an instance var for the sole purpose of unregistering the callback when the owner (a window controller) was being torn down. The better way (IMO) was to change the basic call from:
>
> void RegisterAuthenticationCallback(void (^)())
> void UnregisterAuthenticationCallback(void (^)())
>
> to:
>
> void RegisterAuthenticationCallback(id, void (^)())
> void UnregisterAuthenticationCallbacks(id) // note slight change in semantics, cannot unregister a single cbk
>
> So now the callback is keyed on the owner, a simple change in the underlying class, but we're back to clients just have to register & unregister without any temp vars nor cycle-breaking.
You lost me at “I”, because it’s not clear whether you are the library or the client at that point. Was ‘authfun’ a property of the window controller (the client/owner?) or something in the library?
Is the ‘id’ in the new API a reference to the window controller/client/owner? And it’s keyed because the reference is literally a key in a dictionary inside the library whose value is a completion block?
Actually, I think I have it. Originally, the block pointer was the client identifier, but then you changed the identifier to an “arbitrary” pointer supplied by the client. So, originally, the client had to keep a reference to the block to serve as identifier later.
I think your new API is superior, but I do want to ask: for the original API, why could not ‘authfun’ just have been weak?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden