Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115011
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CA+kxMuQ5AkOmgoidX2Mt+y31B=6SwLctCcr6S+s5jf7boH=omA@mail.gmail.com>
Date: Tue, 22 Jun 2021 05:25:42 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E319A50E-D120-4B9B-88F5-6BDBEC64B374@newclarity.net>
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <CAOwTYAt3rztsZ1BTjEbsonqPR_thgG7UqEUO2pKeN=dEg1jqgg@mail.gmail.com>
 <CA+kxMuSJvk2bDM1dQnZHxgiO+YrYhbjS8BziAy+YGSSW8cR1nw@mail.gmail.com>
 <f7288bfd-e9e6-f77e-358b-c0d6fe12a9d9@nunninger.info>
 <CA+kxMuQ5AkOmgoidX2Mt+y31B=6SwLctCcr6S+s5jf7boH=omA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Subject: Re: [PHP-DEV] [RFC] is_literal
From: mike@newclarity.net (Mike Schinkel)

> On Jun 22, 2021, at 4:53 AM, Dan Ackroyd <Danack@basereality.com> =
wrote:
>=20
> The whole point of the idea of literal strings is to make it be easier
> to write some code that:
>=20
> i) is safe.
> ii) can be reasoned about at scale.
>=20
> Passing bare strings around is not so great for either of those
> things. You have to manually remember "this is a string that is
> intended to be used in a particular way. And doing that in a large
> code base, when your engineering department is large enough to work in
> separate teams is particularly difficult.
>=20
> Instead of using bare strings, using a more specific type e.g.
> HtmlAttribute::fromString('#fff'); and then passing that around would
> be much easier to reason about.

THIS.

> Similarly for the thoughts about concatenating numbers into strings.
> Yeah, people might think they want that, but in practice using an SQL
> builder that allows you to put the number in the right place like:
>=20
> $sqlBuilder->add('SELECT * FROM foo LIMIT %d', FIXED_LIMIT);
>=20
>=20
> And then predictable when the request comes in to allow users to set
> their own limit, changing it to:
>=20
> $sqlBuilder->add('SELECT * FROM foo LIMIT %d', $_GET['limit']);
>=20
> Doesn't take any time to refactor the code, because it's already using
> an appropriate library that handles variables correctly.

So, IMO this begs the question:=20

Should(n't?) PHP add a basic SQL builder class that can be extended for =
special cases, e.g. different flavors of SQL? =20

The problem with depending on userland to do this is that there will =
never be a single standard adopted.

If built into PHP it could:

1. Legitimize it across all PHP developers,=20
2. To make sure its always available in the most basic PHP install,=20
3. To allow implementing a performant SQL parser (which is not =
reasonably done in PHP),
4. To make creating a target for polyfills for prior versions possible,=20=

5. And to create a standard that all PHP projects that use SQL can =
adopt?

-Mike
P.S. PHP could also implement a sanitizing templating language for SQL =
as possibly a different or even additional approach.=