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
