Thanks! 🙌🏻 Actually, I often use the very same Medium posts for my research, adding just a couple things on top. I do some extra fact-checking (and even after that I don’t expect anyone to just trust my word, hence the links in the description). I try to present the data in a more visual format (although I still don’t have enough time to implement _all_ of my ideas). And then, I wrap everything in a cohesive narrative. The last part is probably the most important ingredient because (for me, at least) seeing the connections and big picture makes understanding stuff much easier (e.g. weak refs have certain properties for which the side table is needed, and the way the side table works calls for certain object-lifecycle steps). Like, everything affects everything, and I’m trying to untangle those connections 😄
Why does an object still remain in memory when in deinited state? From my understanding ARC proxies all the access operations and the only thing it has to deal with to raise exceptions (unowned) or return nil (weak) is a side table.
Hi! While the side table keeps track of the all three counts, it acts as a proxy _only_ for weak references. Unowned refs point directly to the object, not the side table. So as long as you have unowned references, you also need to have _something_ at their memory address.
So much better than lots of medium articles, precisely explained!
Thanks! 🙌🏻
Actually, I often use the very same Medium posts for my research, adding just a couple things on top. I do some extra fact-checking (and even after that I don’t expect anyone to just trust my word, hence the links in the description). I try to present the data in a more visual format (although I still don’t have enough time to implement _all_ of my ideas). And then, I wrap everything in a cohesive narrative.
The last part is probably the most important ingredient because (for me, at least) seeing the connections and big picture makes understanding stuff much easier (e.g. weak refs have certain properties for which the side table is needed, and the way the side table works calls for certain object-lifecycle steps). Like, everything affects everything, and I’m trying to untangle those connections 😄
Perfect explanation, keep it up 👏🏻
Thank you!
This video is a must indeed! The most condensed and almost clear info I've ever encountered.
Wspaniale przekazana wiedza! Twórz więcej!
Dziękuję!
More of this content ❤
Why does an object still remain in memory when in deinited state? From my understanding ARC proxies all the access operations and the only thing it has to deal with to raise exceptions (unowned) or return nil (weak) is a side table.
Hi! While the side table keeps track of the all three counts, it acts as a proxy _only_ for weak references. Unowned refs point directly to the object, not the side table. So as long as you have unowned references, you also need to have _something_ at their memory address.
💖