> On Jun 26, 2021, at 10:03 AM, Craig Francis wrote:
>
> Just a quick reply at the moment, but what happens if a db library had a
> method to set what was in the LIMIT part of a query, you did the MySQL thing
> of “30, 10” to get paginated results, and then one day the library changed to
> req
Just a quick reply at the moment, but what happens if a db library had a
method to set what was in the LIMIT part of a query, you did the MySQL
thing of “30, 10” to get paginated results, and then one day the library
changed to require the argument to be an integer?
On Sat, 26 Jun 2021 at 2:51
The idea behind is_literal() is of good intention, but as they say the road to
hell is paved with good intentions.
The RFC proposes to add an internal "literal" flag to a string, the
is_literal() function, and nothing else.
Further the RFC states a vision to get "libraries to start using is_l
On Fri, 25 Jun 2021 at 23:21, Craig Francis wrote:
>
> We're going back to the original is_literal() proposal.
Please stop adding my name as a contributor to this RFC.
I explicitly removed my name from the document yesterday when I first
realised it was there.
I don't support the RFC as it is.
Craig,
On Fri, 25 Jun 2021 at 23:21, Craig Francis wrote:
>
> We're going back to the original is_literal() proposal.
>
> https://wiki.php.net/rfc/is_literal
The RFC still contains carrying the string literal flag through string
concatenation, which is still not a good idea.
And it still doesn'
On Sat, Jun 26, 2021 at 1:21 AM Craig Francis wrote:
> We're going back to the original is_literal() proposal.
>
> https://wiki.php.net/rfc/is_literal
Nice work! `chr()` returning literal strings is somewhat questionable,
but otherwise this is looking very good.
--
Best regards,
Bruce
