Throw assertion when attempting to inject section changes on AppKit

[helje5]

Section changes are not supported yet on AppKit (neither
NSCollectionView nor NSTableView, see issues #93/#94).

Checklist

• All tests are passed.
• [-] Added tests.
• [-] Documented the code using Xcode markup.
• Searched existing pull requests for ensure not duplicated.

Description

Just added a single assertion to both extensions:

            assert(changeset.sectionChangeCount < 1,
                   "NSCollectionView sections are not yet supported, sorry.")

Related Issue

• Support for NSTableView sections (aka group rows) #93 for NSTableView
• Support NSCollectionView sections #94 for NSCollectionView

Motivation and Context

Without the assertion, the extensions silently drop changes / do the wrong thing. This way we can at least catch them in debug mode.

Impact on Existing Code

No impact.

Screenshots (if appropriate)

[ra1028]

I prefer NSCollectionView to support sections instead of asserts.
On the other hand, NSTableView can't support sections, but I don't think it needs assertions.

[ra1028]

@helje5
Please let me know if you disagree with my thought.

[helje5]

To be honest I don't understand what you are saying / trying to say :-)

I prefer NSCollectionView to support sections instead of asserts.

You mean you prefer DifferenceKit to support NSCollectionView sections? Yeah, I'd prefer that too, but while that isn't available, asserts seem to be way to go? Otherwise people, like me, run into this and wonder why it isn't working.

On the other hand, NSTableView can't support sections, but I don't think it needs assertions.

You mean you prefer DifferenceKit to support NSTableView groups (same like sections, just w/ a different API)? Yeah, I'd prefer that too, but while that isn't available, asserts seem to be way to go? Otherwise people, like me, run into this and wonder why it isn't working.

[ra1028]

@helje5
Ah sorry, I realized that I had written a rather nonsensical comment as you say.
I mean that NSCollectionView should actually be able to support sections, so it's better to implement it than to make assertions.
Does this PR help you?
And then, in my understanding, NSTableView doesn't have an API to support sections.
I agree that it's reasonable to make assertions so that users can see why it's not working at this point.
However, it's also important to avoid crashing the app if something goes wrong, so we need to carefully determine when and where to assert.
Assertions that are too sensitive will provide a painful API like the UICollectionView as we've been experiencing.
IMO, the natural thing to do in this case would be to keep working rather than crashing immediately. what do you think?

[helje5]

I mean that NSCollectionView should actually be able to support sections, so it's better to implement it than to make assertions.

I agree! And until that works, have the assertion, a one line change.

Does this PR help you?

Don't have the time right now to check it out, maybe?

And then, in my understanding, NSTableView doesn't have an API to support sections.

Your understanding is wrong. NSTableView has groups which is the same thing like UIKit sections, it just has a (quite) different API for that. So the task here would be to either provide a fascade which makes it work, or have a version of the algorithm running against the tableview representation of the data.
IIRC I actually played with building that, but eventually stopped due to time constraints.

I agree that it's reasonable to make assertions so that users can see why it's not working at this point.
However, it's also important to avoid crashing the app if something goes wrong

Assertions only stop the app when building them in debug mode. They exist specifically to help during development and are inactive when building in release mode.

I think there is no reason not to enable them.