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.
