Nice TWiki > Dev > CurrentDiscussions > ClassInvariants TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
I'm looking ahead to when invariants are added, and the crossover with NiceConstructors. Vague thoughts only, feel free to edit.

There's an Eiffel hack to allow different sets of invariants in different conditions: express your invariants as

invariant_name: condition implies [<an invariant set>]
The trouble with using this for constructors is you have to list what parts of the invariant each method really depends on in each method, which defeats the purpose of an invariant.

I wondered about a distinction between methods that preserve the invariant but don't require it, which could be freely called both within constructors and outside them, and ones that both preserve and require. Note that this is a different situation again to constructors, which do not require the invariant but guarantee to make it satisfied: a preserving-only method would not necessarily make it satisfied if it wasn't when the method was called. The problem with this arises when the preserve-only method is called directly after some buggy method has broken the invariant. The preserve-only method doesn't do the proper checking, because it's happy to accept a broken invariant at method start.

My suggestion is a general condition in_constructor which is set true at the start of each constructor and false at its end. Preserve-only methods guarantee to check the invariant

For this to work with nested constructor calls I guess constructors only set it to false at end if it was false before they set it at start, or something.

Anyway, this is entirely off-the-cuff uninformed thinking out loud, with no idea how implementation-practical the idea is.

-- SamsonDeJ - 15 May 2003

It's a good idea to start with high-level thoughts about the design. If a feature is well designed, it is usually easier to implement it, and of course it makes the language more beautiful.

Could you comment on the proposal in NiceConstructors? If we can separate the construction from the initialization, then there is the possibility to get rid of this invariant problem altogether.

By the way, I appreciate to have somebody fluent in Eiffel to participate in here. It can give a different perspective, and contribute to a richer discussion. Knowing the existing is a must to improve over it.

-- DanielBonniot - 16 May 2003

I would also appreciate hearing from someone who knows Eiffel. Unfortunately it's not me - I know a very little about Eiffel, and picked the above off a webpage. -- SamsonDeJ - 16 May 2003

Topic ClassInvariants . { Edit | Attach | Ref-By | Printable | Diffs | r1.4 | > | r1.3 | > | r1.2 | More }
Revision r1.4 - 06 Jun 2003 - 18:48 GMT - DanielBonniot
Parents: WebHome > CurrentDiscussions
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.