Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69621
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,=?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>
Message-ID: <525FEB6D.2060907@php.net>
Date: Thu, 17 Oct 2013 14:51:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <D7.A0.22512.AE09F525@pb1.pair.com> <1382014199.3980.249.camel@guybrush>
In-Reply-To: <1382014199.3980.249.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Assertions
From: krakjoe@php.net (Joe Watkins)

On 10/17/2013 01:49 PM, Johannes Schlüter wrote:
> On Thu, 2013-10-17 at 08:25 +0100, Joe Watkins wrote:
>> Morning All,
>>
>> 	I'd like to draw some attention to how poor assertions are in PHP.
>>
>> 	The current assertion API is not usable in my opinion; it has a
>> considerable overhead, relies on eval(), and is generally poorly
>> implemented.
>
> I don't have a strong opinion on this, but mind that by being based on
> eval the assert expression can use features from a different version of
> PHP. Something like
>
>     if (PHP_VERSION_ID >= 50300) {
>         assert('foo\\bar::baz == 42');
>     }
>
> the new form
>
>     if (PHP_VERSION_ID >= 50300) {
>         assert foo\\bar::baz == 42;
>     }
>
> would give a parse error on older versions.
>
> (Yes, I'm using 5.3 and <5.3 as example where the new form would fail
> anyways, feel free to use PHP_VERSION_ID >= 51200 and PHP 5.26.0
> features)
>>
>>          This means that assert("some code here") will pass assertion
>> causing no error, because strings are no longer treated as code,
>> because eval is evil();
>>
> I think this is bad for migration of code. For one it is impossible to
> have a code base with asserts working in both versions. For two it
> silently leads to completely different behavior. Changing this needs
> some clever strategy allowing migration.
>
> johannes
>
>

Okay, so if the expression used is a string, it is now evaluated, this 
provides some backward compatibility and the possibility to avoid 
compilation of the expression at compile time...

Better ??

Cheers
Joe