clear() and UFCS

[Alex Rønne Petersen]

On 25-05-2012 17:59, Steven Schveighoffer wrote:
> On Fri, 25 May 2012 11:42:57 -0400, Alex Rønne Petersen
> <alex at lycus..org> wrote:
>
>> On 25-05-2012 17:37, Steven Schveighoffer wrote:
>>> On Fri, 25 May 2012 11:28:07 -0400, Alex Rønne Petersen
>>> <alex at lycus..org> wrote:
>>>
>>>> On 25-05-2012 17:23, Steven Schveighoffer wrote:
>>>>> On Fri, 25 May 2012 11:03:33 -0400, Alex Rønne Petersen
>>>>> <alex at lycus..org> wrote:
>>>>>
>>>>>> On 25-05-2012 16:56, Steven Schveighoffer wrote:
>>>>>>>
>>>>>>> Wow, you're right, it's not documented. That should be fixed!
>>>>>>
>>>>>> Before we do, we should deprecate clear and rename it to finalize,
>>>>>> though.
>>>>>
>>>>> I don't like finalize because it's not a finalizer.
>>>>>
>>>>> I think we should mimic other languages that have a finalizer and a
>>>>> deterministic dispose function.
>>>>>
>>>>> -Steve
>>>>
>>>> But it calls rt_finalize...?
>>>
>>> Yeah, because non-deterministic destruction is part of deterministic
>>> destruction.
>>>
>>> finalize -> destroy non-gc resources
>>> dispose -> 1. do deterministic destruction involving possible GC
>>> resources 2. call finalize.
>>>
>>> e.g. a buffered file:
>>>
>>> finalize -> close the file handle
>>> dispose -> flush the GC allocated buffer into the handle, then close the
>>> handle
>>>
>>> -Steve
>>
>> But if clear() *does* run the finalizer *now*, then finalize would be
>> a better name, no?
>>
>> I'm all for the dispose model, but then we need a way to suppress
>> finalizers too.
>
> This is what I think clear (or function to be named later) should do:
>
> if(obj.dispose())
> rt_finalize(obj);
> else
> rt_suppressFinalize(obj);
>
> That way you can write code like this:
>
> class File
> {
> bool dispose()
> {
> flush();
> return true;
> }
>
> ~this()
> {
> close(handle);
> }
> }
>
> and you don't have to repeat the finalize code inside the dispose
> routine if it's a normal part of deterministic destruction.
>
> -Steve

Sounds good to me.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org