Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.55.154.21 as permitted sender)
Message-ID: <000701c7f91b$55fb3c30$4001a8c0@pc07653>
To: =?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>
Cc: "Peter Brodersen" <penguin@php.net>,
	<internals@lists.php.net>
References: <001f01c7f6f0$dbcf5350$4001a8c0@pc07653> <j4hne3p0eksfcbqc0ostdj6cv56052abnq@4ax.com> <002201c7f894$1b236060$4001a8c0@pc07653> <1189983923.17667.24.camel@johannes.nop>
Date: Mon, 17 Sep 2007 12:10:20 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: RFC: mark functions as const for possibleoptimizations
From: nlopess@php.net ("Nuno Lopes")

> On Sun, 2007-09-16 at 20:02 +0100, Nuno Lopes wrote:
>> > >My proposal is the following:
>> > >some functions when fed with constant arguments always return a 
>> > >constant
>> > >value, too. e.g.:
>> > >strlen('abcd') === 4.
>> >
>> > I like the general idea.
>> >
>> > Would there be some caveats with stuff like this if it is possible to
>> > change the charset at runtime?
>> >
>> > I guess it is important to be aware of whether a function is affected
>> > by different settings (and if these settings can be changed at
>> > runtime) to conclude if a function really is deterministic at this
>> > level.
>>
>> uhm, damn, right. strlen() wasn't a good example.. my bad, sorry :S
>> Anyway, you got the idea :)
>
> Nothing wrong with strlen as far as I can tell:
>
> - In PHP 5 we only have binary strings so strlen() works independent
>  from any charsets and encodings by just counting bytes.
> - In PHP 6 we know - assuming the parameter is a constant string - the
>  encoding at compile time, therefore it could be used.
>
> The only edge-case I see is if somebody uses mbstring.func_overload and
> overwrites strlen()


exactly. I was thinking in mbstring, too. As long as there is some run-time 
setting that can affect a function, we cannot replace its call blindly with 
its value. Then only a more intelligent optimizer can do inference on the 
code and figure out if it's safe or not to replace the function call.
My proposal was to mark functions susceptible of that "blind" replacement 
only.

Nuno