Invariants for methods

[Jens Mueller]

bearophile wrote:
> Jens Mueller:
> 
> > I don't like the "old" approach.
> 
> Why?
> (It's the canonical way to solve the problem you have had. It is present in Eiffel and C# and probably something similar is present in the DbC for Java. But surely other solutions are possible.)

Somehow it doesn't feel right to me. It should just copy what is needed.
Let's say I have some very big object. Now old is a copy before the
execution of my member function. But I only check some little detail but
I end of with having this big copy. I think the programmer knows what
she's doing and she should have control about it. This copying behind the
scenes seems surprising to me. Maybe I do not fully understand the
approach.

> > Don't get your point here. You neither like the ghost fields (old) nor
> > the debug {} approach as Andrei suggested?
> 
> I have written that answer of mine before reading Andrei answer.

I see.

> > I mean after all the problem
> > is not that important that one should bother too much.
> 
> The problem is important enough. In DbC it's very useful to have a safe&notbugprone way to test if a method has changed the precedent state correctly.

I've seen the Java's Request for Enhancements you mentioned. DbC is
number one. You're right one should do this properly but it seems to me
that right now there are more important problems. I mean I do not know
when people started complaining about Java missing proper DbC but I'll
guess it was a lot later. If it starts itching then scratch it. I hope
there is no inherent design problem. I think this problem does not
prevent D's success. I might be wrong here but nobody is not switching
to D because this does not work. It's more the bugs/API changes/tools
that keep people away. At least that's my impression. It does not seem
mature enough for some people.

Jens