.. plus if anyone calls [ xxx bytes ] on any of the shared NSMutableData objects it must be copied incase the bytes are mutated and I'm sure there are a load more edge cases.
You cannot say 'immutables copied are just retained and mutableCopied are COW'. There is no way to know that without having all the Cocoa source, the first is fairly likely true across most immutable objects but not guaranteed, the second is very much an optimisation/implementation detail which may or may not be applied in some, many, all, or no cases for a given class. There's a lot of classes in Cocoa, I would be fairly surprised if all of them used the exact same memory management methodology and I would not be surprised if there exists at least one class who's mutableCopy method just allocates new memory and copies the data and doesn't even think about COW at all. I would guess more than one. The good thing about copy and mutableCopy is they can be implemented any way the programmer likes as long as they return an object which is a copy or a mutable copy of the original, assuming that mutability/non-mutability even applies to that type. How they do it is entirely left to the implementer. On 27 Apr, 2014, at 10:24 pm, Britt Durbrow <bdurb...@rattlesnakehillsoftworks.com> wrote: > Oh, and if you are implementing something like this, don’t forget to trap > writes to both the copy *and* the original object: > > myMutableClass *a=[myMutableClass makeAnObjectWithSomeBuffer:aBuffer]; > myMutableClass *b=[a mutableCopy]; > > [a mutateTheBuffer]; > > doing [a isEqual:b] should return NO; but if you didn’t trap the write to the > original object and cause the COW copies to actually do the copy then it will > erroniously return YES (and all sorts of other havoc will likely ensue…) > > > On Apr 27, 2014, at 4:06 AM, Maxthon Chan <xcvi...@me.com> wrote: > >> Immutables copied are just retained and returned, and mutableCopied are COW. >> >> Mutables copied generates COW. >> >> That would be the fastest way implementing that. >> >> * COW = copy on write >> >> On Apr 27, 2014, at 17:06, John McCall <rjmcc...@apple.com> wrote: >> >>> On Apr 27, 2014, at 2:00 AM, Dave <d...@looktowindward.com> wrote: >>>> A long time back, I remember reading something about the way in which copy >>>> and mutableCopy are implemented. I think basically it said that: >>>> >>>> someObject = [someOtherObject copy]; >>>> >>>> or >>>> >>>> someObject = [someOtherObject mutableCopy]; >>>> >>>> Wouldn’t necessarily allocate any extra data storage. I’ve been searching >>>> for it to refresh my memory, but I can’t see to find it anywhere. Does >>>> anyone know if this document or something like it exists somewhere? >>> >>> I don’t know if there’s a document, and like a lot of things with ObjC the >>> actual guarantees are pretty weak, but implementations of these methods on >>> immutable types have been turning into essentially “return [self retain];" >>> for quite some time. But that’s when the actual dynamic type is >>> guaranteed-immutable, e.g. something constructed as an NSArray, not just >>> something that’s immutable by convention, e.g. an NSMutableArray that >>> you’re passing around as an NSArray. >>> >>> John. >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> 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: >>> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com >>> >>> This email sent to xcvi...@me.com >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com >> >> This email sent to bdurb...@rattlesnakehillsoftworks.com > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
