Re: [NSData initWithBytesNoCopy:length:deallocator:]

[Richard Frith-Macdonald]

> On 27 Jul 2016, at 01:04, Niels Grewe <address@hidden> wrote:
> 
> 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?


The next release of base is planned to be 1.25.0 (I've already started updating 
the news/release-notes to that effect in svn) since, as announced in the last 
release, it will be removing GC support (and making other binrary incompatible 
changes).
There are already too many changes in trunk to realistically make another 
bugfix release in the 1.29.? series from it.
So up until we actually make the 1.25.0 release any binary incompatible changes 
are fine in trunk.

signature.asc
Description: Message signed with OpenPGP using GPGMail