Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115378
MIME-Version: 1.0
Date: Fri, 09 Jul 2021 13:49:50 +0300
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Craig Francis <craig@craigfrancis.co.uk>, PHP internals
 <internals@lists.php.net>
In-Reply-To: <CAF+90c8DbBajg7yukYkyXeJp2RU3JngLcr_zJdP=tOw9ebb6ag@mail.gmail.com>
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CAF+90c8DbBajg7yukYkyXeJp2RU3JngLcr_zJdP=tOw9ebb6ag@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <5144ede56329a246e0c95469d887bb79@gmail.com>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=)

On 2021-07-07 12:23, Nikita Popov wrote:
> permanent interned strings, which will be predominantly (or entirely?)
> non-literal. At least it doesn't look to me like names of internal
> functions/classes/etc are considered literal. I think this may be
> problematic, in that now the permanent non-literal interned string in 
> the
> function/class tables will be different from the per-request literal
> interned string used by user code to reference it.

Just wondering, if this is a major performance problem, is there a 
compelling reason why the internal names couldn't be marked literal 
(even if it's technically "wrong")? It seems unlikely to get a function 
or class name accidentally in a SQL query and even less likely that user 
input was involved.

-- 
Lauri Kenttä