Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain broadpark.no from 80.203.156.252 cause and error)
Message-ID: <0ca501c6d709$0cc74020$a900000a@adstate.local>
To: <internals@lists.php.net>
Date: Wed, 13 Sep 2006 09:48:49 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Const member functions
From: tslettebo@broadpark.no (=?iso-8859-1?Q?Terje_Sletteb=F8?=)

(This may be considered too radical for some, but I ask, anyway... Also, if
there's a more appropropriate place to ask such questions, let me know, but
as this is the developer's list, it seemed like the right place)

In C++, it's possible to declare member functions "const" meaning they don't
change the object they operate on. This can help reason about programs,
because if you have something like (PHP syntax):

function some_member()
{
   ...
   $a = $this->f();
   $b = $this->g();
   $c = $this->h();
   ...
}

and f(), g() and h() are all declared "const", you know the object is still
in the same state as before the functions were called. I was recently "bit"
by this, when I changed the state in a member function, and later called
that member function, thinking it _didn't_ change the state, and wasted some
time debugging that. Had it been possible to declare your assumption (this
function doesn't change the object), I'd got an error where it did change
the object, clearly showing the erroneous assumption.

Thoughts?

As I'm pretty ignorant about the internals of PHP, I don't know if this is
practical to implement, or whether it might "fit" with the language.

It's possible to _simulate_ this effekt to some degree, but at the cost of
both syntactic noise and performance: In short, it's a hack. It involves
creating an object at the start of the function definition, taking a
reference to $this, and comparing the new state with a copy of it, in the
destructor (i.e. at the end of the function). However, it's a rather
inelegant "solution", with a potentially large performance impact.

Regards,

Terje