Temporary suspension of disbelief (invariant)

[Fawzi Mohamed]

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

> Fawzi Mohamed wrote:
>> 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.
>
> I agree that having a method that destroys an object can be useful.  
> Such classes can't have an invariant, however.
>
> The problem with an @invalidate property is the user has to go  
> through every declaration in the class looking for such a property  
> (grep isn't sufficient because it can pick up false positives  
> (nested functions) and can miss things inserted by templates and  
> mixins). An invariant should be a guarantee, not "this is guaranteed  
> unless someone somewhere violates it, which is perfectly legal".
>
> It's the same problem that C++ "mutable" produces, and it's not  
> worth it.


the only thing is that the invariant is not checked *after* those  
method that destroy the object, it will be ok to require a special  
name for that method (for example destroy, dealloc or similar) if you  
want to avoid misusage.
The next method called on the object would fail (as it should), I  
often store invalid info on purpose before deleting to increase the  
probability of detecting such usages.
invariant is still valid (and checked) before and after all methods.
It is even impossible to call twice the destroy method (as the check  
at the beginning of it would fail.
So I think that everything would stay perfectly well defined.
I think it is a different situation than mutable