Temporary suspension of disbelief (invariant)

Walter Bright newshound2 at digitalmars.com
Wed Oct 27 11:57:46 PDT 2010


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.


More information about the Digitalmars-d mailing list