On Sep 16, 2015, at 11:45 , Ken Thomases <k...@codeweavers.com> wrote: > > This is not legitimate. The -willChangeValueForKey: must occur before the > property, as seen via its getter, has changed. This is necessary for > observers who ask for the old value, which can include KVO itself for key > paths which go through the property.
I’m not sure that it’s illegitimate by API contract. In addition, we know that certain Cocoa mechanisms using KVO (such as observations created via keyPathsForValuesAffecting<Key>) don’t ever provide an old value at all. But I agree that this all (meaning the contortions to get updates onto the main thread) seems like too much flash and not enough bang. The easiest way would be to dispatch the original update code in blocks onto the main thread asynchronously, thus serializing them and generating KVO notifications safely. When I think about it in those terms, it’s clear (to me, at least) that the *real* problem is one of coalescing a potentially large number of updates over time. In other words, this thread is really about premature optimization and its ugly consequences. FWIW. _______________________________________________ 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
