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
