On Sunday, 25 August 2013 at 16:22:01 UTC, Andrei Alexandrescu
wrote:
On 8/25/13 5:16 AM, deadalnix wrote:
As they are defined now, invariant are plain useless. I find
myself
disabling them one by one in my code as soon as cases get
outside simple
trivia.
The problem is that invariant are checked at the beginning/end
on public
function calls. As a consequence, it is impossible to use any
public
method in an invariant.
But this is what they are for - check the state of an object
upon access through the client-accessible interface. Simple
code factorization (use a private method forwarded to by the
public one) takes care of this situation.
Yes that can be worked around, but the code ends up more and more
complex, with many function forwarding to one another.
This can become very messy with class hierarchies.
For instance, just right now I did refactor a struct to use
bitfields,
in order to make it more compact. Now I have to remove the
invariant as
field access are now function calls.
I don't get this case. Code?
struct Identifiable {
union {
Symbol sym;
Expression expr;
Type type;
}
import d.ast.base : TypeQualifier;
import std.bitmanip;
mixin(bitfields!(
Tag, "tag", 2,
TypeQualifier, "qual", 3,
uint, "", 3,
));
@disable this();
// For type inference.
this(typeof(null));
this(Identifiable i) {
this = i;
}
this(Symbol s) {
tag = Tag.Symbol;
sym = s;
}
this(Expression e) {
tag = Tag.Expression;
expr = e;
}
this(QualType qt) {
tag = Tag.Type;
qual = qt.qualifier;
type = qt.type;
}
}
I used to have an invariant that check the sanity of the tagged
union, but now I have to double the interface to the bitfield.
This one is still fixable by doubling the interface, but the same
thing with the bitfield in a super class from another module and
you are doomed.
Another typical situation is when you want to assert certain
properties
in a class hierarchy, where calling virtual method is part of
the
invariant check.
invariant should (and must to be useful) be inserted at callee
point,
when the callee isn't itself subject to invariant insertion,
and around
public memeber manipulation (when the manipulator isn't
subject to
invariant insertion).
Any other pattern it doomed to create infinite recursion for
non trivial
invariant checks.
There might be something here, but more like a performance
problem. I do see how calls of public methods from an invariant
could cause trouble, but I'd say that's a problem with the
invariant design.
Andrei
This is a performance issue as well. But mostly it makes
invariant useless in many cases when class hierarchies are in
place and probably the worst part is that invariant are not even
ensured as they do not trigger when writing to public fields (as
triggered by the callee, and we have no callee in this case).
