[swift-users] What is the intended response to Array change notification for dependents?

[Jens Alfke]

> On Mar 7, 2017, at 9:28 AM, Michael Gardner via swift-users <swift-users at swift.org> wrote:
> 
> The general approach would be to run a diff between your old and new arrays. Something like https://github.com/jflinter/Dwifft <https://github.com/jflinter/Dwifft> could help, though I haven't used it personally.

I’ve implemented something like this in the past. It’s fairly expensive, though; that library does claim to use an optimized algorithm, but the cost is still a lot higher than just posting a notification. (And my own experience of using KVO is that notifications can become significant hot spots in performance, because they happen a lot.)

On the other hand, if the array is expected to change often, more often than you want to redraw the GUI, it could make sense to ignore the fine-grained changes and just set a timer to trigger after a few hundred ms, which would then compare the old and new arrays this way and apply a minimal update to the view.

> Another approach is to build a wrapper around your source array with limited modification methods and a KVO-like notification system. The notifications can map cleanly to UITableView updates, and there's no extra diffing calculations involved. Of course, this method won't work if your source array needs to be modified by code you don't control.

I would favor this, even though Swift’s strict typing [and lack of inheritance in struct types] means this class can’t interoperate with regular arrays. (Vs. Objective-C, where you can either subclass NSMutableArray, or even make an unrelated class that walks & quacks like an NSArray.)

This seems likely to have been created by someone already; I wonder if there’s an implementation floating around Github?

—Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170307/87f32421/attachment.html>