[NSData initWithBytesNoCopy:length:deallocator:]

[Niels Grewe]

Hi guys,

I just implemented the -initWithBytesNoCopy:length:deallocator: initialiser for 
NSData and NSMutableData (this appeared in OS X 10.9). This takes a block as 
the last argument which allows you to customise how memory will be deallocated. 
This is very useful when you have a memory buffer whose lifetime is tied to 
some other resource that you want to discard once the NSData is no longer 
needed.

Unfortunately this required adding an ivar to hold the block, so there is a 
slight complication: To maintain strict binary compatibility, NSDataMalloc and 
NSMutableDataMalloc instances will deallocate themselves if called with this 
initialiser and return a new object of the correct subclass instead. This could 
be avoided if we added the block ivar to NSDataMalloc and NSMutableDataMalloc 
directly, but that’d break any consumers subclassing these classes (assuming 
the fragile ABI).

Now I am of the opinion that since NSData is a class cluster, nobody should 
have any business subclassing these anyways, but I wanted to solicit some input 
on the issue before making this kind of change: Would it be acceptable to make 
this a common ivar? Should we bump the minor version to indicate that this 
might be a breaking change or do we regard the internal organisation of the 
class cluster as an implementation detail that we can change on a whim?

Thanks,

Niels

signature.asc
Description: Message signed with OpenPGP using GPGMail