On Mon, 26 Jan 2015 05:25:48 +0000, Bayan Rafeh wrote: > There are 2 problems here: > > 1. By definition, after the destructor is called the object state is > destroyed. It makes no sense to check the invariant after the destructor > is called because there is no state for us to check. i agree that calling invariant after destruction is invalid. i believe that this is a bug.
> 2. Invariants theoretically describe the legal states the object can be > in which includes variables that are GC managed, therefore I should be > able to check the invariant on GC managed objects as well. What's the > point of having this feature if I can't even check the invariants of a > simple data structure like a set, let alone classes involving files? checking something that is not owned by an object is invalid. invariants MUST NOT be dependent on external data or system state. invariants that tries to check for GC objects ARE dependent of external state. let alone invariants that checking for files, which can be removed while the object is still alive. object can own another object, but it can't own another object *state*. if you want to check something that involves checking something like that, you should use `assert()`s in function body and/or in/out function parts. you are trying to use invariants for the things that invariants can't (and must not) check. invariants are meant for checking *internal* *object* *consistency*. NOT correctness. NOT applicability. ONLY consistency. object can be in "inapplicable" state, but still consistent.
signature.asc
Description: PGP signature
