• "Pavel \"EvilOne\" Minayev" <evilone omen.ru> Nov 11 2001
• John Nagle <nagle animats.com> Nov 11 2001
• Axel Kittenberger <axel dtone.org> Nov 11 2001
• "Pavel \"EvilOne\" Minayev" <evilone omen.ru> Nov 11 2001
• "Walter" <walter digitalmars.com> Nov 29 2001

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


 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.