Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112353
To: internals@lists.php.net
References: <b845d5bf-63da-d564-1f0f-cc934188d693@aimeos.com>
Message-ID: <e7e2927c-63aa-8390-393f-8811d2c622a2@gmail.com>
Date: Tue, 1 Dec 2020 11:50:13 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <b845d5bf-63da-d564-1f0f-cc934188d693@aimeos.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP 8 is_file/is_dir input handling
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> In PHP 7, this returns FALSE:
> 
> php -r 'var_dump(is_file("ab\0c"));'
> 
> In PHP 8, the same code throws a ValueException. Problem is now that

I think this is a mistake. Exceptions should not be thrown on such 
values, it only breeds boilerplate code (now you'd have to wrap each 
call to is_* into try/catch or add another pre-call validator just to 
ensure it doesn't throw). PHP type system is not robust enough to 
support fine-grained types like "string that has certain format", and 
pretending we do have this as a type and throwing typing error on it 
only makes the consumer work harder for no additional gain. In almost 
every situation I can imagine, string that is not the name of the file 
is equivalent to string that is not the name of the file and also has \0 
in it. However, this setup forces me to treat them differently and add 
additional validation step to it. While to some functions it may be a 
useful functionality - specifically to constructor functions expected to 
return an object, so they can't really tell "you gave me invalid data" 
other than throwing - for something like is_file it will only be annoying.
-- 
Stas Malyshev
smalyshev@gmail.com