Temporary suspension of disbelief (invariant)

Fawzi Mohamed fawzi at gmx.ch
Wed Oct 27 11:46:33 PDT 2010


On 27-ott-10, at 20:20, Walter Bright wrote:

> 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.
>
> It's not an invariant if it only works some of the time.
>
> It's like C++ and the mutable keyword, which allows an escape from  
> the const rules. Which makes C++ const fairly useless.
>
> A person should be able to see the invariant in a class declaration,  
> and know that it offers a guarantee. He should not be required to  
> read over everything else in the source code looking for the absence  
> of a method that disables it.


well for methods that destroy the object I think that not checking the  
invariant is something reasonable, and not a hole that destroys the  
whole system. Being able to write methods that invalidate the object  
can be useful IMHO.
At the moment in those objects I simply have no invariant, and by the  
way, no I don't think that having the invalidating methods always  
external is really a good solution.
You can do without, but sometime an @invalidate property (or similar)  
has its uses.

Fawzi


More information about the Digitalmars-d mailing list