Here's the code that an (unexperienced) programmer
could write:

    class Control
    {
    public:
        int Left() { return left; }
        int Top() { return top; }
        int Right() { return right; }
        int Bottom() { return bottom; }
    private:
        int left, right, top, bottom;

        invariant()
        {
            assert(Right >= Left);    // note the use of
            assert(Bottom >= Top);    // property-getters
        }
    }

Now this would result in an infinite loop, since
on each call to method invariant block is checked
which calls a method... etc. Mistake is especially
easy to commit if method is a property-getter.
Maybe any method calls on "this" should be forbidden
in invariant blocks?

BTW, why () after "invariant"? unittest doesn't have
them, nor do try, in/out/body...

Pavel \"EvilOne\" Minayev wrote:
> 
> Here's the code that an (unexperienced) programmer
> could write:
> Now this would result in an infinite loop...

   Properly, you shouldn't be allowed to call a public
method from a private method, because the public method
assumes you're outside the object, and the private method doesn't
reestablish the invariant before the call.

   This is probably too formalist, but it's right.

					John Nagle

John>    Properly, you shouldn't be allowed to call a public
John> method from a private method, because the public method
John> assumes you're outside the object, and the private method doesn't
John> reestablish the invariant before the call.
John>
John>    This is probably too formalist, but it's right.

Thats far to strict in my eyes, against the paradigm, and from the human programmers view people will feel nothing but beeing pestered.

I would vote for not writing this extra 'access functions' which do nothing but return a private class variable. Why not create a new access level for variables called maybe "show". Anyone may read it, but only the class internal routines itself may modify it.

- Axel
-- 
|D) http://www.dtone.org

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9smksj$2qfc$1@digitaldaemon.com...

> Thats far to strict in my eyes, against the paradigm, and from the human programmers view people will feel nothing but beeing pestered.

Agreed.

> I would vote for not writing this extra 'access functions' which do
nothing
> but return a private class variable. Why not create a new access level for variables called maybe "show". Anyone may read it, but only the class internal routines itself may modify it.

This was just an example. In real program, it'd probably call GetWindowRect (in fact, it does already, but that's another story =)). And in general, I try to always use getters & setters since I can't be 100% sure that this variable won't be needing them later... so it'd be better not to break compatibility. Besides, with all those aggressive optimizations that D is supposed to perform, I believe the resulting code is no slower than usual member variable access.

As for the "show" access level - yes, it would be useful. There are many cases when you want a variable to be read but not written from outside, without getters and other helper constructs. So I vote for it.

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9snmng$emt$1@digitaldaemon.com...
> Besides, with all those aggressive optimizations that D is supposed to perform,

<g> D is designed make aggressive optimization possible, but of course it will always be a quality of implementation issue.