Under the headline “Adding Undo to RaiseMan” (p457 in iBooks) the code for registering undos makes the mistake of appending the employee of a redo-operation at the end instead of the original location where it was deleted from.
in the method insertObject(employee: Employee, inEmployeesAtIndex index: Int)
instead of
the last line needs to be
Please add this to the errata file.
Can you say why that is a mistake? In other words, what difference do you see in how your app works if you make the change you recommend? Do you remember the difference between the Array Controller’s content array and the arrangedObject’s array?
I asked about append(), too; and I discussed what I think are more serious problems here:
viewtopic.php?f=523&t=10352
Sorry if I was unclear.
When I delete a row from the table that is not the last row, and then undo the deletion, the row is added back at the end of the table and not at its original position.
That would be the incorrect part.
About the arrangedObjects vs. contentArray
I checked and can’t see how this could be relevant here. Neither KVC Accessor uses those properties. (Please point out my blindness if present)
If the table was sorted before the removal, sorting it again after undoing and hence appending the removed entry at the end would also fix the problem, but that is just…
I agree with some criticism that the chapter would benefit from a bit more explanation (especially what most of the code really does when implementing the “edit immediately” functionality).
About your concerns over willSet/didSet modification of observers
In my opinion the book shows a very simple way to accomplish what it needs.
Your concern about speed depends on the amount of employees there are. Should we have thousands of employees you would probably be right and the individual handling of observers on every employee would be better, but otherwise this
willSet { employees.forEach { stopObservingEmployee($0) } }
has linear efficiency O(n) (same as for-in).
I agree with you that the book could mention the fact that this could be improved for an array with many employees or better yet give a better solution (similar to yours) once the reader has grasped the overall concept of the code.