Temporary suspension of disbelief (invariant)
Fawzi Mohamed
fawzi at gmx.ch
Wed Oct 27 11:46:33 PDT 2010
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
More information about the Digitalmars-d
mailing list