I do think a decent compromise is to recognize which elements of a project are really worth the extra effort. If you’re making a billion instances of something then it’s time to do the necessary work. If there’s a part that never or rarely needs to get totally removed I suppose you can use weak references or–gasp–just let the memory leak go. I’m not suggesting people become “pussies” but step 1 is to notice when it matters most.

1) weak references are more expensive then strong. they take longer to process.

2) you never know when a weak reference will get garbage collected.

Now if my team is working on a project that WE built. Then yeah: RCOK DESTORY. But if we jump into the middle of a project we didn’t build where we could miss a destory or dont have time to crawl through all their code to add it then using weak references may not be a bad idea imo.

-erik

I just came across this and a great article. Hope all is well with the family! Here is something to ponder… Since you love to build applications (great ones if I do say so), then you need to find someone that loves to build the business side and partner with them ;o)

FYI, we should do lunch sometime when you down by me!

Jeremy