[PHP-DEV] Handler(s) and priority for == and != opcodes
Hello internals, Following the rejection of the operator overloads RFC I have looked at bringing some mathematical improvements to PHP in extensions instead. As part of this, there is one truly blocking issue: The opcodes for == and != are handled by the compare handler. On zend_class_entry, extensions can define a handler for do_operation which allows them to overload operators. As I described in the op overloads RFC, this is something that extensions and C code can fully accomplish, it's just restricted for userland code. However, currently the following operators are handled by the compare handler instead: >, >=, ==, !=, <=, <, <=>, <> The reason this is a problem is that in mathematics (and presumably other domains), it is possible for something to be *equatable* but not *sortable*. For example, consider the following: `2 + 1i == 2 + 1i` This should return true. However: `2 + 1i >= 2 + 1i` This should either return false or throw an exception or error. Complex numbers are *not* comparable, but they *can* be equal or not equal. To accomplish this, the zend_class_entry handlers *must* provide a way for the ==, !=, and <> opcodes to be handled separately if desired. I discussed this issue briefly with nikic, joe, and cmb. Both nikic and cmb expressed understanding of the issue and a tentative understanding of the value of this change, while joe didn't provide any negative feedback. I'd like to alter the VM and possibly zend_class_entry in order to accomplish this. This can be done in a BC compliant way, meaning that it's an internal engine change that doesn't require an RFC. However chris brought up the point that this could be accomplished by *either* sending the relevant opcodes to the do_operation handler or to a brand new handler. The PR for the first option (sending it to do_operation) can be viewed here: https://github.com/php/php-src/pull/7973 I'd like to gather feedback on whether it's more appropriate to send this to the do_operation handler or to create a new handler. Jordan
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider wrote: > > My issue with this is that while it seems to work towards the goal of > "fail fast" it does not completely fulfill its promise. > > Pardon me, but this argument seems rather impotent. Only fully realized features are allowed? What if there is not agreement on the details of some of the edgecases? Something better should be rejected because it's not something perfect? This is an attitude I have encountered from management at jobs before, but seems very odd to me from a development perspective. The proposed error may not be good as its own change (personally I could go either way on it), but this particular explanation is not a reason to vote against something, it is a rationalization. There may be good reasons to object to this, but I'd like to hear what those are instead. Jordan
RE: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
> Any type error should if you ask me. Unexpected types cause unexpected > behavior, and the longer PHP will try to continue with assumptions of types > and implicit casting, the bigger the damage can be. All this type juggling is > headache material and the less I see of it, the better. Sorry for derailing, but out of interest - why choose a loosely typed language in the first place then? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On Fri, Jan 28, 2022 at 3:13 PM Robert Landers
wrote:
> I would posit differently. In my experience in upgrading code, it was
> mostly intentional.
> Here's an example:
>
>
> if($doThing) {
> $doOtherThing = maybe();
> }
> // later
> if($doOtherThing) {
> doOtherThing();
> }
> ---
>
> There's no bug here, nothing is unintentional, and the intent is clear.
> Now,
> if we want to get rid of the warning we need to say $doOtherThing = false
> before getting to the first if-statement, but should this halt everything
> in
> production? I don't personally think so and it would be undesirable for it
> to do so.
>
Let me go over this.
> There's no bug here, nothing is unintentional, and the intent is clear
I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell whether or
not this code is suffering from a merge conflict, and I cannot guarantee
that whatever type `maybe();` returns here works. If at some point the
return type of `null` is changed to `false`, while the assumption of
undefined is `null`, passing `false` to a nullable typed argument later on
will break.
> Now, if we want to get rid of the warning we need to say $doOtherThing =
false before getting to the first if-statement
Thank you for pointing to the example above. `null` and `false` are
different values. Your assumption here is that setting it to `false` would
fix the problem, but the actual value would've been `null` and changing it
to `false` might actually break more.
> but should this halt everything in production? I don't personally think
so and it would be undesirable for it to do so.
Any type error should if you ask me. Unexpected types cause unexpected
behavior, and the longer PHP will try to continue with assumptions of types
and implicit casting, the bigger the damage can be. All this type juggling
is headache material and the less I see of it, the better.
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
Hi,
> So what we're talking about here is changing the engine's definition of
> what is safe
One of the benefits of PHP is it's resilience in the face of user input.
The
only time this isn't desired is in a security context (SQL queries,
authentication, etc). Most applications are not operating in a security
context 100% of the time so your definition of "safe" may not be
appropriate for other people's projects.
> I would posit that the vast majority of reads
> on undefined variables are in fact unintentional side effects from
> branching logic and are not the real intention at all.
I would posit differently. In my experience in upgrading code, it was
mostly intentional.
Here's an example:
if($doThing) {
$doOtherThing = maybe();
}
// later
if($doOtherThing) {
doOtherThing();
}
---
There's no bug here, nothing is unintentional, and the intent is clear. Now,
if we want to get rid of the warning we need to say $doOtherThing = false
before getting to the first if-statement, but should this halt everything in
production? I don't personally think so and it would be undesirable for it
to do so.
Robert Landers
Software Engineer
Utrecht NL
On Thu, Jan 27, 2022 at 11:41 PM Mark Randall wrote:
> On 27/01/2022 22:09, Larry Garfield wrote:
> > I am not sure what additional value is gained by making the scream even
> louder.
>
> For us to make something an exception at engine level, is to stop
> execution on the grounds that the engine no longer considers it safe to
> continue.
>
> That might be because a boolean was passed to a function that expects a
> string, or in this case it might be because an undefined variable has
> been read.
>
> Notices / Warnings are irrelevant to this under the default
> configuration, as in the absense of a userland error handler the engine
> will happily allow code to continue executing even after a probably
> undesirable state has been detected.
>
> So what we're talking about here is changing the engine's definition of
> what is safe to exclude read operations on an undefined variable.
>
> I understand the argument that the behaviour is well defined, at least
> for some operations, but I would posit that the vast majority of reads
> on undefined variables are in fact unintentional side effects from
> branching logic and are not the real intention at all.
>
> If someone is insistent on working with nulls, there is an easy to use,
> fully backwards compatible way to avoid these errors, which is to define
> a variable as null prior to any branching logic.
>
> For everyone else, we should offer this entirely sensible safety net.
>
> What we don't want to do, I think, is end up in a situation like JS
> where it has to be opted in: https://www.w3schools.com/js/js_strict.asp
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
Am 27.01.2022 um 23:41 schrieb Mark Randall : > What we don't want to do, I think, is end up in a situation like JS where it > has to be opted in: https://www.w3schools.com/js/js_strict.asp That's why the majority decided a while ago that you don't have to opt-in right now: The default error_reporting level shows a warning. What you want to do is take away the option of *opting out* of this warning. And that's where I disagree. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
