Haha. Awesome! I didn’t even know this existed… thanks for the tip :-)
> On May 17, 2015, at 6:30 PM, Graham Cox wrote:
>
>
>> On 18 May 2015, at 11:14 am, Jonathan Hull wrote:
>>
>> Instead of having a central object pool, have the objects adhere to a
>> protocol which takes a method to b
> On 18 May 2015, at 11:14 am, Jonathan Hull wrote:
>
> Instead of having a central object pool, have the objects adhere to a
> protocol which takes a method to be called in low-memory situations
Yep. You could call it ‘NSDiscardableContent’ ;)
—Graham
I would avoid messing with the retainCount.
Have you looked at using NSCache to retain the objects in your pool?
Other approaches that you could try:
1) Your central object pool has an array which holds a strong reference to the
objects, and has a method (that can be called in a low-memory situ
On May 17, 2015, at 18:10 , Quincey Morris
wrote:
>
> I think you are on the right track with this, but instead of partitioning the
> objects into two containers, put all the objects in one container.
Er, I meant “put all the objects in both containers”.
On May 17, 2015, at 17:47 , Britt Durbrow
wrote:
>
> Also, I did think of having the objects in the graph that are supposed to be
> held on to be held in a strong container, and the objects not currently being
> held on to in a weak container, but that doesn’t work because then the
> objects
Ughh… I find myself in a bit of a quandary:
I have a pool of disk-backed (well, flash-backed on iOS) objects that have an
arbitrary graph structure. These are managed by a central object pool. The
object pool is supposed to cache these in memory (creating them is somewhat
non-trivial), and hold
As others already noted the standard way is using the continue keyword.
However, if the conditional inside is scoped high enough, you can also just use
a guard if () {}
Putting everything inside the if block.
Then like any guard it's going to do nothing if the condition is false.
Most Objectiv
