Re: Dispose patern (was: Re: GC pros and cons)
Re: Dispose patern (was: Re: GC pros and cons)
- Subject: Re: Dispose patern (was: Re: GC pros and cons)
- From: "Stephen J. Butler" <email@hidden>
- Date: Sun, 28 Jun 2009 12:27:56 -0500
On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davie<email@hidden> wrote:
> On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
>> I still have to read much more about the GC used within Objective-C /
>> Cocoa so I am not sure, if I am not writing some kind of "bullshit" from
>> your view:
>>
>> Isn't it possible to simply flag an object to be removed? Is there a
>> dispose pattern in Objective-C?
>> (e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a
>> pattern in C#)
>>
>> Something like that would simply more the world together again. That way,
>> the developer has some more control, the GC has less work and all are maybe
>> happy?
>>
>> So is there such an Dispose Pattern in Objective-C using a GC or is there
>> nothing like that?
>
> That sounds exactly like reference counting – and it suffers from all the
> well known problems (like retain cycles). The point here is that you don't
> *want* the developer to have control, the developer (myself included) is
> really really bad at doing this, and introduces a *lot* of bugs in the
> process.
>
> The option for it of course will keep everyone happy, but that doesn't mean
> it should be encouraged ;)
Again, IDisposable in C# has nothing to do with early
destruction/deallocation of the object. It's purpose to is perform
explicit cleanup of external resources, resources not managed by the
GC system. For example: file handles, sockets, OS system handles, etc.
Calling Dispose() on a C# system does not mark the object for early
collection (AFAIK). It still has to pass through the GC like any other
object. In fact, disposed objects may still be useful long after they
are disposed (perhaps they contain connection statistics, fetched
data, or something else).
Objective-C already has an informal IDisposable. Any class with a
"close" message is essentially doing the same thing.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden