> > On May 20, 2015, at 10:32 AM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > Turns out they weren’t so much off track as you need a smack upside the head. > [Er, wait, you’re a big dude with a beard, so perhaps kittens instead? You > like kittens? I don’t want to get hurt.] >
Um… no; that was an example of what *NOT* to do. It was supposed to show what *won’t* work, and what I mean by “loss of graph coherency". Sorry if that wasn’t clear… We are, in fact, on the same page at this point! :-) > ** In practice there may be a little something more in the way of > housekeeping. If you’re selectively releasing things from the cache, you > might need to keep track of what you did, so that you re-retain the correct > subset of OPC references later. If you don’t need to be selective, it’s > easier because you just release everything in OPC at the start of the memory > event, and re-retain everything in OPC [that still has a non-nil pointer in > OPC] at the end. The document objects in question happen to have a flags field in their base class with some unused bits that I’m going to dedicate to tracking that state. ******************************************************************************************************************************************************* > > On May 20, 2015, at 9:09 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: > The flaw in this example is that VC1 continuing to use DMO1 even after it has > told OPC that it’s done with it is a programmer error. It would be if the system was using something akin to NSDiscardableContent… but remember, there is a body of legacy code that I am trying to disturb as little as possible by making the memory management as automatic as possible. Also, generally speaking, I don’t want to have to go back to a manual retain/release model for the whole app (which is basically what using NSDiscardableContent entails; even though it isn’t literal -retain and -release calls; the pitfalls are similar). ******************************************************************************************************************************************************* > On May 20, 2015, at 5:45 AM, Roland King <r...@rols.org> wrote: > > No that’s not what he wants to achieve. He wants > > 1) When he needs an object pertaining to a given UUID he wants > 1.1) if it doesn’t exist - to create it and keep it mapped to the UUID in > some manner such that > 1.2) if it does exist he just returns the same object as before. > > There can never be two objects living which represent the same thing (ie > UUID) > <snip> Basically, yes. There’s some implementation details involved, but that’s a pretty good summary of the problem… and after doing some more testing, I *think* I have an approach now that will work well enough (some of my initial intuitive concerns didn’t pan out - figures, premature optimization being the hazard that it is; and other things are worse than I thought they were such that the additional overhead of implementing weak links isn’t as high as I thought it would be; and then there’s the explicit retain/release step that Quincey suggested that cuts out having to have two separate containers for the object pool). _______________________________________________ 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
