Implement ordered set accessors

[danielctull]

The Apple generated accessors for ordered sets crash, this is described further in the radar bugs listed below.

I've added implementations for ordered to-many relationships, but because of Xcode will warn you about not implementing all the methods in a category, I've separated each relationship's accessor method declarations.

After two iterations of OS I would have thought they would have fixed this bug. :-/

Those radars:
http://openradar.appspot.com/10946479
http://openradar.appspot.com/12085926
http://openradar.appspot.com/11119497
http://openradar.appspot.com/12418689

[rentzsch]

I'm not sure this patch fixes the problem.

Try re-enabling the section in mogenerator/test/test.m that has the comment "Unforunately this section..." and running rake in the test dir.

With the section enabled and without this patch, I'm seeing the old broken NSInvalidArgumentException behavior under 10.8.2/Xcode 4.5.2.

With your patch the insertion doesn't immediately raise an exception (yay!), but the relationship doesn't seem to be populated (NSCAssert([homer.children count] == 2, nil); fails).

[danielctull]

Sorry for the delayed response, I thought I'd go away and come back with an answer, but in reality I've not had the time. I ran the tests and saw the failure, and this has given me doubt about using ordered sets at all, because it likely explains what I was seeing in my project.

Given deadlines, the solution I've used is to avoid using ordered sets. :-/

[rentzsch]

@danielctull No problem, we're all busy. Thanks for this and your previous patches.

[rentzsch]

For reference, here's Graham Lee's workaround:

to get them working with bindings I created a custom NSMutableArray subclass that wraps the ordered set

[richardbuckle]

I think I may have got to the bottom of this.

According to Apple's Key-Value Coding Programming Guide, for an ordered relationship we should not declare methods of the form add<Key>Object: and remove<Key>Object:, but of the form insertObject:in<Key>AtIndex: and removeObjectFrom<Key>AtIndex:, and optionally replaceObjectIn<Key>AtIndex:withObject: or replace<Key>AtIndexes:with<Key>:.