Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Dmitry Stogov]

Hi Nikita,


Yeah, this is a big BC break, but I think, it's a good time to make some 
"cleanup" in PHP-8.

The only thing, I don't like is a difference between leading and trailing 
spaces.

They should behave in the same way.


Thanks. Dmitry.


From: Nikita Popov 
Sent: Tuesday, February 26, 2019 3:27:23 PM
To: PHP internals
Subject: [PHP-DEV] [RFC] Saner string to number comparisons

Hi internals,

I think it is well known that == in PHP is a pretty big footgun. It doesn't
have to be. I think that type juggling comparisons in a language like PHP
have some merit, it's just that the particular semantics of == in PHP make
it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
returns true.

I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
and other non-strict comparisons, when used between a number and a string:

https://wiki.php.net/rfc/string_to_number_comparison

The tl;dr is that if you compare a number and a numeric string, they'll be
compared as numbers. Otherwise, the number is converted into a string and
they'll be compared as strings.

This is a very significant change -- not so much because the actual BC
breakage is expected to be particularly large, but because it is a silent
change in core language semantics, which makes it hard to determine whether
or not code is affected by the change. There are things we can do about
this, for example the RFC suggests that we might want to have a transition
mode where we perform the comparison using both the old and the new
semantics and warn if the result differs.

I think we should give serious consideration to making such a change. I'd
be interested to hear whether other people think this is worthwhile, and
how we could go about doing it, while minimizing breakage.

Regards,
Nikita

Re: [PHP-DEV] [RFC][Vote] Weakrefs

[Sebastian Bergmann]

Am 26.02.2019 um 21:37 schrieb Marco Pivetta:

Just posting to clarify on my "No" vote: I am generally against having more
features that (by design) introduce spooky action as a distance behavior,
especially on references.


I voted "No" for similar reasons.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Weakrefs

[Marco Pivetta]

Hi Joe,

On Fri, Feb 22, 2019 at 12:54 PM Joe Watkins  wrote:

> Morning all,
>
> The vote for weakrefs is open: https://wiki.php.net/rfc/weakrefs
>
> Cheers
> Joe
>

Just posting to clarify on my "No" vote: I am generally against having more
features that (by design) introduce spooky action as a distance behavior,
especially on references.

The fact that this might be useful for tools like doctrine/orm is (in this
specific example) mostly because Doctrine\ORM has a very leaky design
concept (UnitOfWork) at its core, and most folks don't want to micro-manage
it, but would rather defer memory management to the engine.

While it is true that weakrefs introduce a technical solution for those
folks, they also open pandora's box when it comes to managing in-memory
state, and yet another code location to constantly monitor with the
debugger, which is something that I'm not looking forward to.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] Re: [RFC] New custom object serialization mechanism

[Nikita Popov]

On Tue, Feb 19, 2019 at 11:42 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:

>
>
> Le mar. 19 févr. 2019 à 11:31, Nikita Popov  a
> écrit :
>
>> On Mon, Feb 18, 2019 at 4:12 PM Nicolas Grekas <
>> nicolas.grekas+...@gmail.com> wrote:
>>
>>> Hi Nikita,
>>>
>>> I'd like to propose a new custom object serialization mechanism intended
 to replace the broken Serializable interface:

 https://wiki.php.net/rfc/custom_object_serialization

 This was already previously discussed in
 https://externals.io/message/98834, this just brings it into RFC form.
 The latest motivation for this is https://bugs.php.net/bug.php?id=77302,
 a compatibility issue in 7.3 affecting Symfony, caused by Serializable. We
 can't fix Serializable, but we can at least make sure that a working
 alternative exists.

>>>
>>> Is there anything we can to do to help the RFC move forward? I'm
>>> spending a great deal of time removing Serializable from the Symfony code
>>> base. It's not pretty nor fun... but we have no choice since as ppl move to
>>> PHP 7.3, they can now spot when the current mechanism is breaking their
>>> serialized payloads (typically from user objects put in the session
>>> storage).
>>>
>>> About interface vs magic methods, technicaly, we can work with an
>>> interface provided by PHP core, so that if that's a blocker for voters to
>>> approve the RFC, let's do it - the current situation is really aweful :).
>>> FYI, I found myself implementing some getState()/setState() methods of my
>>> own, decoupled from the underlying mechanisms used by PHP. That allows me
>>> to still use Serializable for BC reasons when needed, or  move to __sleep
>>> when possible, then move to the new 7.4 style when ready, without requiring
>>> any changes from the consumer POV. That's a good illustration of what I
>>> meant in my previous email: domain-specific interfaces in everyone's code
>>> is a better design as it allows better decoupling. It's also a better
>>> design to express that "instances of this interface of mine MUST be
>>> serializable". IMHO.
>>>
>>> Nicolas
>>>
>>
>> I think for me the main open question here is whether we want to just
>> handle the serialization issue or try to come up with something more
>> general. If we limit this to just serialization, then the design should
>> stay as-is -- for all the reasons you have already outlined, using an
>> interface for this is inappropriate.
>>
>> For a more general mechanism, I think we would need something along the
>> lines of (ignoring naming):
>>
>> interface GetState {
>> public function getState(string $purpose): array;
>> }
>> interface SetState {
>> public function setState(array $data, string $purpose): void;
>> }
>>
>> We need separate interfaces for get/set to properly cater to cases like
>> JSON, where only get is meaningful (right now). We need the $purpose
>> argument to allow different state representations for different purposes,
>> e.g. JSON will often need more preparation than PHP serialization. The
>> $purpose argument is a string, to allow extension for custom purposes.
>>
>> Seeing that, this is really not something I would feel comfortable with
>> introducing in core PHP. Our track record for introducing reusable
>> general-purpose interfaces is not exactly stellar (say, did you hear about
>> SplObserver and SplSubject?) and I wouldn't want to do this without seeing
>> the concept fleshed out extensively in userland first.
>>
>> Nikita
>>
>
> I think the per-purpose representation logic doesn't belong to each
> classes.
> Symfony Serializer does it completly from the outside, and I think that's
> a much better design.
> I'm on the side this should not be in PHP code indeed.
>

As there hasn't been further input here, I'd like to go forward with the
RFC as-is and plan to start voting by Friday.

Nikita

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Rowan Collins]

On 26 February 2019 13:26:24 GMT+00:00, Nikita Popov  
wrote:
>I'm mentioning this, because it is a precedent for tweaking the string
>to
>string numeric comparison rules to prevent unexpected and possibly
>security
>critical equalities. I think we could add similar special handling for
>the
>"0e" == "0e" case, as this is another "catastrophic" case when
>it
>comes to comparisons of hashes that happen to start with 0e, for
>example.

That makes sense. Personally, I find the treatment of strings in this 
e-notation problematic in all contexts - it makes is_numeric() much less useful 
for validation, for instance - but realise we have to balance compatibility 
here.


>It might be better to discuss such a change separately from this
>proposal
>though (it's much more minor, and something that can also conceivable
>go
>into a minor version, given that the previous change was applied in a
>patch
>release).

I think keeping it to a separate RFC is fine, but it would be nice to target 
the same release. "We've made == safer" is something that we can shout about, 
even if it's composed of a bunch of small tweaks. It also gives one upgrade 
where people need to look for subtle breaks, rather than two.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Nikita Popov]

On Tue, Feb 26, 2019 at 2:06 PM Rowan Collins 
wrote:

> On Tue, 26 Feb 2019 at 12:27, Nikita Popov  wrote:
>
> > I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
> > and other non-strict comparisons, when used between a number and a
> string:
> >
> > https://wiki.php.net/rfc/string_to_number_comparison
> >
>
>
> Hi Nikita,
>
> Thanks for tackling this; I think if we can improve this, we'll be
> answering a lot of language critics (I'm sure they'll find something else
> to complain about, but that's life!).
>
> However, I'm concerned that it doesn't go far enough, when you say that the
> following will still return true:
>
> 0 == "0e214987142012"
> "0" == "0e214987142012"
>
> I think the cases where this is useful are vastly outweighed by the cases
> where it's completely unexpected, and potentially dangerous (e.g. in a hash
> comparison). If this is not fixed, the "dogma to always avoid non-strict
> comparisons" you refer to will remain.
>
> If I understand it right, this arises from the fact that "0e214987142012"
> is considered a "well-formed numeric string", which is cast to int(0) or
> float(0). Is it feasible to also narrow this definition as part of the same
> change?
>

Yes, that's right. However, it's probably worth mentioning that string to
string comparisons are subject to additional constraints beyond the
well-formedness requirement. Since PHP 5.4.4 there are additional overflow
protections in place, which prevent numeric comparison from applying when
both sides are integers that overflow to double and become equal as a
result of that. This means that "1" ==
"10001" returns false rather than true since PHP 5.4.4.

I'm mentioning this, because it is a precedent for tweaking the string to
string numeric comparison rules to prevent unexpected and possibly security
critical equalities. I think we could add similar special handling for the
"0e" == "0e" case, as this is another "catastrophic" case when it
comes to comparisons of hashes that happen to start with 0e, for example.

It might be better to discuss such a change separately from this proposal
though (it's much more minor, and something that can also conceivable go
into a minor version, given that the previous change was applied in a patch
release).

Regards,
Nikita

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Rowan Collins]

On Tue, 26 Feb 2019 at 12:27, Nikita Popov  wrote:

> I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
> and other non-strict comparisons, when used between a number and a string:
>
> https://wiki.php.net/rfc/string_to_number_comparison
>


Hi Nikita,

Thanks for tackling this; I think if we can improve this, we'll be
answering a lot of language critics (I'm sure they'll find something else
to complain about, but that's life!).

However, I'm concerned that it doesn't go far enough, when you say that the
following will still return true:

0 == "0e214987142012"
"0" == "0e214987142012"

I think the cases where this is useful are vastly outweighed by the cases
where it's completely unexpected, and potentially dangerous (e.g. in a hash
comparison). If this is not fixed, the "dogma to always avoid non-strict
comparisons" you refer to will remain.

If I understand it right, this arises from the fact that "0e214987142012"
is considered a "well-formed numeric string", which is cast to int(0) or
float(0). Is it feasible to also narrow this definition as part of the same
change?

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[G. P. B.]

On Tue, 26 Feb 2019 at 13:27, Nikita Popov  wrote:

> Hi internals,
>
> I think it is well known that == in PHP is a pretty big footgun. It doesn't
> have to be. I think that type juggling comparisons in a language like PHP
> have some merit, it's just that the particular semantics of == in PHP make
> it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
> returns true.
>
> I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
> and other non-strict comparisons, when used between a number and a string:
>
> https://wiki.php.net/rfc/string_to_number_comparison
>
> The tl;dr is that if you compare a number and a numeric string, they'll be
> compared as numbers. Otherwise, the number is converted into a string and
> they'll be compared as strings.
>
> This is a very significant change -- not so much because the actual BC
> breakage is expected to be particularly large, but because it is a silent
> change in core language semantics, which makes it hard to determine whether
> or not code is affected by the change. There are things we can do about
> this, for example the RFC suggests that we might want to have a transition
> mode where we perform the comparison using both the old and the new
> semantics and warn if the result differs.
>
> I think we should give serious consideration to making such a change. I'd
> be interested to hear whether other people think this is worthwhile, and
> how we could go about doing it, while minimizing breakage.
>
> Regards,
> Nikita
>

I am in favor of this change however I do think having the Trailing
Whitespaces numerics RFC
would be better for this change as I do agree with you that IMHO 42 == "42
" should return true.
I'm also not sure if you maybe should point this out sooner but as it is
currently seems fine to me.

However small nitpick on your precision section

$float = 1.75;
 ini_set ('precision', 14); //
Defaultvar_dump ($float < "1.75abc");//
Behaves likevar_dump ("1.75" <
"1.75abc"); // true

is wrong because var_dump($float < "1.75abc"); returns false:
https://3v4l.org/G56Vj
I think you meant to use the <= comparison operator maybe?

Also the NAN behavior is a bit surprising (to me atleast) but it does
follow the IEEE-754
However I don't really understand why it always returns 1 with the TIE
operator.

And finally as to how to do the transition I don't really have a strong
opinion about it.
An INI setting seems like this behavior is going to be supported for a long
time.
But it doesn't seem like its possible to throw deprecation notices to alert
of this change.

Best regards

George P. Banyard

[PHP-DEV] [RFC] Saner string to number comparisons

[Nikita Popov]

Hi internals,

I think it is well known that == in PHP is a pretty big footgun. It doesn't
have to be. I think that type juggling comparisons in a language like PHP
have some merit, it's just that the particular semantics of == in PHP make
it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
returns true.

I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
and other non-strict comparisons, when used between a number and a string:

https://wiki.php.net/rfc/string_to_number_comparison

The tl;dr is that if you compare a number and a numeric string, they'll be
compared as numbers. Otherwise, the number is converted into a string and
they'll be compared as strings.

This is a very significant change -- not so much because the actual BC
breakage is expected to be particularly large, but because it is a silent
change in core language semantics, which makes it hard to determine whether
or not code is affected by the change. There are things we can do about
this, for example the RFC suggests that we might want to have a transition
mode where we perform the comparison using both the old and the new
semantics and warn if the result differs.

I think we should give serious consideration to making such a change. I'd
be interested to hear whether other people think this is worthwhile, and
how we could go about doing it, while minimizing breakage.

Regards,
Nikita