Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
Hi,
Il 03/05/2024 17:53, Hans Henrik Bergan ha scritto:
On Fri, 3 May 2024 at 17:49, Derick Rethans wrote:
Which *API* in PHP is 1-indexed?
cheers,
Derick
Certainly isn't normal but found 1 (and only 1!):
$stmt = $pdo->prepare('SELECT name FROM users WHERE id = ?');
$stmt->bindParam(1, $id);
I suppose numbering is derived from external (database) standards. E.g.
Postgres uses $1, $2, etc. as parameter placeholders.
Also it is in turn is inconsistent with:
$stmt = $pdo->prepare('SELECT name FROM users WHERE id = ?');
$stmt->execute([$id]);
That said, 0-indexed for the reflection PR seems the best choice to me too.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Fri, 3 May 2024 at 17:49, Derick Rethans wrote:
>
> Which *API* in PHP is 1-indexed?
>
> cheers,
> Derick
Certainly isn't normal but found 1 (and only 1!):
$stmt = $pdo->prepare('SELECT name FROM users WHERE id = ?');
$stmt->bindParam(1, $id);
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Fri, 3 May 2024, Gina P. Banyard wrote: > On Thursday, 2 May 2024 at 21:33, Derick Rethans wrote: > > > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote: > > > > > These methods accept an integer to retrieve a parameter by its > > > position, or a string to retrieve by its name. So far, I have > > > built this so that if you required the first parameter, it's > > > parameter 0. I treat it this way because the only other place > > > where we deal with parameter indexes, is > > > ReflectionFunctionAbstract::getParameters() which returns the > > > parameters zero-indexed. > > > > > > The question that is holding this PR back is should these methods > > > be 1 indexed, so that the provided position is consistent with the > > > error messages, or how a person would typically count, or should > > > they be 0 indexed to remain consistent with the existing API. > > > > 0-indexed, as that's what PHP does everywhere else. > > Well not really, if you have an error (TypeError or ValueError) which > indicate what parameter is the problem, it will be 1-indexed. Which *API* in PHP is 1-indexed? cheers, Derick
Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers
Hi internals! I've updated once again the RFC and implemented most of the 3 major dialects (mysql, pgsql, sqlite) in the drivers. https://wiki.php.net/rfc/pdo_driver_specific_parsers https://github.com/php/php-src/pull/14035 I've tried to keep syntax changes we might not want as separate commits in the PR. For example: - the pdo_pgsql driver now also understands C-style escape strings and dollar quoted strings. - pdo_sqlite supports Access-style [identifiers]. - pdo_mysql will consider "--" a comment only when followed by whitespace. The latter has been a particular challenge for me and I've been able to overcome it by using the re2c:eof feature, which I then discovered being available only in a later version compared to our requirements (1.2.1, released Aug 2019). As is, the Windows build fails on GH because the sdk ships with 1.1.1. Perhaps someone with better re2c knowledge can get it working with re2c 1.0.3+, or perhaps it's not really worth it. Looking forward to hearing from you! Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Fri, May 3, 2024, at 1:45 AM, Gina P. Banyard wrote: > On Thursday, 2 May 2024 at 21:33, Derick Rethans wrote: > > > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote: > > > > > These methods accept an integer to retrieve a parameter by its position, > > > or a string to retrieve by its name. So far, I have built this so that if > > > you required the first parameter, it's parameter 0. I treat it this way > > > because the only other place where we deal with parameter indexes, is > > > ReflectionFunctionAbstract::getParameters() which returns the parameters > > > zero-indexed. > > > > > > The question that is holding this PR back is should these methods be 1 > > > indexed, so that the provided position is consistent with the error > > > messages, or how a person would typically count, or should they be 0 > > > indexed to remain consistent with the existing API. > > > > > > 0-indexed, as that's what PHP does everywhere else. > > > > cheers > > Derick > > Well not really, if you have an error (TypeError or ValueError) which > indicate what parameter is the problem, it will be 1-indexed. > > Which, for me, makes it more logical to have it 1-indexed. > If the ReflectionFunctionAbstract::getParameters() API did not exist, this is > what I would have pushed for. > > Moreover, PHP already has a 1-indexed and 0-indexed discrepancy with the > ob_get_level() and ob_get_status() functions. > > In the end, I don't really care what we choose, but this just needed > clarification from internals on how to proceed. > > Best regards, > > Gina P. Banyard > It looks like the consensus seems to be 0-indexed, but I'm happy to allow it a bit more time to get a few more opinions if you'd prefer. I do totally understand what you're saying, though. I think people are typically already capable of differentiation. We know that the first entry in a list array, so entry 1, is index 0. Not to mention the way getPosition() and getParameters() works. --- Best Regards, *Ollie Read*
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Fri, May 3, 2024 at 9:28 AM Lynn wrote: > > The parameter number always confuses me because parameter 4 is actually > the 4th, not the 3rd like I'd expect if I look at the indexes when > `...$parameters`. > I wish we had a proper system so I could edit my message instead of bothering everyone with an additional reply, I meant to say index 3, not the 3rd parameter.
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Thu, May 2, 2024 at 10:21 PM Benjamin Außenhofer wrote: > > > On Thu, May 2, 2024 at 2:51 PM Ollie Read wrote: > >> Hi All, >> >> I've been working on a PR that introduces >> ReflectionFunctionAbstract::getParameter() and >> ReflectionFunctionAbstract::hasParameter(), to fall more inline with the >> other method sets we have, as well as just generally making peoples lives >> easier. >> >> The PR is here: https://github.com/php/php-src/pull/10431 >> >> These methods accept an integer to retrieve a parameter by its position, >> or a string to retrieve by its name. So far, I have built this so that if >> you required the first parameter, it's parameter 0. I treat it this way >> because the only other place where we deal with parameter indexes, is >> ReflectionFunctionAbstract::getParameters() which returns the parameters >> zero-indexed. >> >> The question that is holding this PR back is should these methods be 1 >> indexed, so that the provided position is consistent with the error >> messages, or how a person would typically count, or should they be 0 >> indexed to remain consistent with the existing API. >> > > PHP being a mostly zero indexed language I would say it should be > getParamter(0) to get the parameter #1 (referred to as 1 in error > messages). > >> >> Girgias has asked that I pause the PR until we can have a discussion on >> this mailing list about how to approach it, so I'm looking for feedback on >> this. >> >> >> --- >> Best Regards, >> *Ollie Read* >> >> The parameter number always confuses me because parameter 4 is actually the 4th, not the 3rd like I'd expect if I look at the indexes when `...$parameters`. Whenever I get an error about parameters I always have to triple check and it costs me extra time to verify the number. I wouldn't mind having this number be consistent with the array indexes instead. I write Lua on a regular basis and everything starts with 1, but it's consistent in the behavior so I never have to think twice.
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
> Le 2 mai 2024 à 14:48, Ollie Read a écrit : > > The question that is holding this PR back is should these methods be 1 > indexed, so that the provided position is consistent with the error messages, > or how a person would typically count, or should they be 0 indexed to remain > consistent with the existing API. > It ought to be consistent with the existing reciprocal method `ReflectionParameter::getPosition()`, which returns `0` for parameter #1. —Claude
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Fri, May 3, 2024 at 4:01 AM Gina P. Banyard wrote: > > On Thursday, 2 May 2024 at 21:33, Derick Rethans wrote: > > > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote: > > > > > These methods accept an integer to retrieve a parameter by its position, > > > or a string to retrieve by its name. So far, I have built this so that if > > > you required the first parameter, it's parameter 0. I treat it this way > > > because the only other place where we deal with parameter indexes, is > > > ReflectionFunctionAbstract::getParameters() which returns the parameters > > > zero-indexed. > > > > > > The question that is holding this PR back is should these methods be 1 > > > indexed, so that the provided position is consistent with the error > > > messages, or how a person would typically count, or should they be 0 > > > indexed to remain consistent with the existing API. > > > > > > 0-indexed, as that's what PHP does everywhere else. > > > > cheers > > Derick > > Well not really, if you have an error (TypeError or ValueError) which > indicate what parameter is the problem, it will be 1-indexed. > > Which, for me, makes it more logical to have it 1-indexed. > If the ReflectionFunctionAbstract::getParameters() API did not exist, this is > what I would have pushed for. > > Moreover, PHP already has a 1-indexed and 0-indexed discrepancy with the > ob_get_level() and ob_get_status() functions. > > In the end, I don't really care what we choose, but this just needed > clarification from internals on how to proceed. > > Best regards, > > Gina P. Banyard There's no discrepancy with ob_get_level and ob_get_status. ob_get_level starts at 0 (no ob) and ob_get_status is count(0) with no_ob. count(ob_get_status(true)) === ob_get_level() Robert Landers Software Engineer Utrecht NL
