> On Jun 22, 2021, at 4:53 AM, Dan Ackroyd <dan...@basereality.com> wrote:
>
> The whole point of the idea of literal strings is to make it be easier
> to write some code that:
>
> i) is safe.
> ii) can be reasoned about at scale.
>
> 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.
>
> 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:
>
> $sqlBuilder->add('SELECT * FROM foo LIMIT %d', FIXED_LIMIT);
>
>
> And then predictable when the request comes in to allow users to set
> their own limit, changing it to:
>
> $sqlBuilder->add('SELECT * FROM foo LIMIT %d', $_GET['limit']);
>
> 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:
Should(n't?) PHP add a basic SQL builder class that can be extended for special
cases, e.g. different flavors of SQL?
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,
2. To make sure its always available in the most basic PHP install,
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,
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
