On Wed, Jun 24, 2009 at 8:19 PM, Jeff Laing<[email protected]> wrote: > Unless you peer into the implementation details of your superclasses, you > should assume that all classes may have a finalizer. Unless you don't care > about every last little piece of performance.
I don't understand your point. If the superclass has a finalizer and implements IDisposable, then you don't need to "peer into the implementation details". Just see if it implements IDisposable and handle appropriately. On the other hand, if it doesn't implement IDisposable yet has a finalizer, then there's nothing you can do about it. You can't implement your own Dispose and call GC.SuppressFinalize(). You're just stuck with whatever you have. So why worry about it at all? Anyway, this discussion has gone way off topic, unless we're using CocoaSharp :) Objective-C objects have different finalize semantics than C# objects, which have different semantics than Java objects. > In my day app, we regularly cache hundreds of thousands of objects from a > persistent (relational) store and it is absolutely critical to us that the > instant that those objects aren't required, they give their memory back - > that's how we can run in a machine with only(?) 1 gig of ram. So I'm one of > those people I mentioned earlier that really really cares that cleanup > happens as soon as possible, not when the fourth or fifth pass through the > queue is done. Can you use weak, zeroing references for the cache? I mean, CoreData theoretically caches large numbers of objects, yet it still works under GC. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
