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