Re: Any way to synthesize KVC compliant collections?
Re: Any way to synthesize KVC compliant collections?
- Subject: Re: Any way to synthesize KVC compliant collections?
- From: Quincey Morris <email@hidden>
- Date: Tue, 12 Oct 2010 11:56:52 -0700
On Oct 12, 2010, at 02:10, Citizen wrote:
> @property NSMutableArray * myArray;
>
> I guess the Writability attributes could be extended to include:
>
> readonlycollection
>
> To generate these with synthisize:
>
> - (unsigned) countOfMyArray;
> - (id) objectInMyArrayAtIndex:(unsigned)theIndex;
> - (void) getMyArray:(id *)objsPtr range:(NSRange)range;
>
>>
>
> readwritecollection
>
> To also generate these with synthesize:
>
> - (void) insertObject:(id)obj inMyArrayAtIndex:(unsigned)theIndex;
> - (void) removeObjectFromMyArrayAtIndex:(unsigned)theIndex;
> - (void) replaceObjectInMyArrayAtIndex:(unsigned)theIndex withObject:(id)obj;
Well, I tried to make this point earlier in the thread:
As far as the property's implementation is concerned, there's no need to @synthesize such methods because they don't need to exist at all *unless* they have developer-written implementations. Conversely, if there's developer-written source code then any @synthesize'd methods will get overridden anyway.
It gets difficult, though, when you consider whether clients of the class should be able to call the KVC accessor methods directly.
For the read-only accessors, it's not a big problem. 'someObject.myArray' is either a real array or a proxy, so it's easy enough to write [someObject.myArray count] (for example) instead of [someObject countOfMyArray]. That is, the read-only KVC accessors don't really need to be part of the class's public API.
For write accessors, it's more complicated. If 'someObject.myArray' is an actual mutable array backing the property, then [someObject.myArray addObject:...] (for example) is no good because it's not KVO compliant. If it's a 'mutableArrayValueForMyArray' proxy, then everything works fine and KVO compliantly, but every access has to go the long way round through the proxy. Also, as I mentioned before, if 'someObject.myArray' simply returns that proxy, any write access at all will put the runtime into an immediate and fatal infinite recursion, due to a historical design defect in KVC. At the very least, you need to use a non-standard method name in place of the simple property getter.
Therefore, it might be desirable for clients to call the insert/remove/replace accessors directly -- they're KVO compliant and don't go round in circles. In that case, it would be justifiable to synthesize the accessors, even though they duplicate functionality that already exists. (Core Data does this for you, for much the same reasons I would guess.)
At a broader level, I'd suggest that the real issue isn't about synthesize accessors, but about the lack of language constructs that generalize collection access in the clients of objects with collection properties. There are too many ways to code an array insertion or removal -- not in itself a bad thing -- but each is tied to a specific and should-be-private technique of implementation -- which *is* a bad thing.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden