Well the second two examples of those are rather different from the first.
In the case of sortedArrayUsingFunction:context: and beginAnimations:context: the context is there really as an opaque pointer to pass data into the function. That pattern of function + <some opaque bag of data I know how to use> was the pre-blocks way to pass contextual information into a generic function, eg say you wanted to sort descending or with some options, that would go in your context in a function-dependent way. Same with beingAnimations:context: (although is anyone using that method any more? That was 'discouraged' after iOS4 and if you aren't using the block-based animations by now .. it's time) again this gave you a way to pass per-animation information in that you wanted to retrieve later. So in those cases the context would usually be a shorter-lived thing used really for the life of the call only and then discarded, often an object cast to void*. the NSKVO context. Technically I suppose you could use that in the same way, if you had an instance of an object which set up more than one observation on the same property of the same other object for more than one reason (I can't think of one offhand but it could happen) you could use the context pointer to disambiguate them and do something different in your observe... method, because you only get one observe method. Most of the time however the context in that exists not to disambiguate between multiple observations of the same property of one object registered by you, but to deal with subclasses observing the same exact property as their superclass on the same object. There will be two observations sent to the instance, each one needs to handle just one of them. In that normal case there you don't care about any actual context of where you set the observation up, you probably don't even care about which instance of your class set it up, you normally just care that this is an observation to be handled in the observe.. method implementation in that particular class, so the generic thing to use is anything at class scope, one of the easiest ways to do that is the static void *X = &X which gives you something only that class has, is already a void*. I've also used the [ xxx class ] properly cast and I think I've used the actual class instance too, probably out of idiocy. On 25 Jul, 2013, at 10:20 PM, Matt Neuburg <m...@tidbits.com> wrote: > I'd like to hear some arguments / opinions / essays on storage of the value > passed as context:(void*), not just in addObserver:, but in general - so, > including things like beginAnimations:context: and > sortedArrayUsingFunction:context:. > > Must it always be an external variable? Must it always be stored as a void*? > I know there's a standard pattern where it's an external pointing to its own > storage: > > static void* const MYCONTEXT = (void*)&MYCONTEXT; > > Is this the only safe/sensible storage? Could it be an actual object, cast > back and forth between id and void*? Could it be stored as an ivar? Thx as > always - m. > > -- > matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ > pantes anthropoi tou eidenai oregontai phusei > Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do > RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html > TidBITS, Mac news and reviews since 1990, http://www.tidbits.com > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
