Temporary suspension of disbelief (invariant)

Stanislav Blinov stanislav.blinov at gmail.com
Wed Oct 27 14:21:21 PDT 2010


Fawzi Mohamed wrote:
> 
> On 27-ott-10, at 18:59, Jonathan M Davis wrote:
> 
>> On Wednesday, October 27, 2010 07:33:58 Fawzi Mohamed wrote:
>>> An issue I encountered in D1 with invariant is using delete: I have a
>>> method that deletes the current object, and obviously then any
>>> invariant would fail.
>>> It would be nice to have a way to disable invariant in that case.
>>> In D2, as delete is not allowed anymore (if I got it correctly) this
>>> is not a problem.
>>
>> Except that calling a function on a deleted object would not be 
>> desirable, so
>> having the invariant fail at that point would be a _good_ thing. If 
>> anything,
>> you'd want _all_ function calls on a deleted object to fail invariant 
>> or no
>> invariant, because none of them should be happening in the first place.
>>
>> clear() in D2 does (or at least did - I don't know what it's current 
>> state is)
>> put an object in its default state prior to any constructor call which 
>> would
>> likely violate any invariant, which, on the whole, is a good thing as 
>> well.
>> However, there was discussion of making a cleared object have a nuked 
>> vtbl which
>> would be even better, since then all function calls on it would fail 
>> period.
>>
>> - Jonathan M Davis
> ...except that clear (just like my dealloc methods) at their end will 
> call the invariant...
> *that* is what I was talking about,
> :)
> Fawzi

What for? It doesn't now, and it shouldn't (and most probably will not) 
when it's design is solid and it's properly implemented.
The purpose of clear() is:
1) call dtor (which implies checking invariant *only before* 
destruction), if object has it.
2) put an object in an invalid (from the compiler/runtime point of view) 
state: this has been discussed at length, and latest discussion ended 
with what Jonathan M Davis already mentioned: nuking object's virtual 
call table.
3) Leave object's memory alone so GC will later decide what to do with it

If I haven't missed something, this is pretty much it. It's not a 
method, it's a function -> no invariant checks after call.


More information about the Digitalmars-d mailing list