On Mon, 14 Jun 2021 at 14:27, Thomas Nunninger <tho...@nunninger.info> wrote:
>
Thomas Nunninger wrote:
Thomas Nunninger wrote:
> Only some (infrastructure or
> end-to-end) test that covers the business logic plus the corresponding
> infrastructure by accident would uncover an error.
I think testing will be much less of an issue than you might expect,
but partly only if string concatenation doesn't carry the flag around.
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.
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.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
