Re: [PHP-DEV] Proposal for a new basic function: str_contains

2020-03-02 Thread Nikita Popov
On Mon, Mar 2, 2020 at 8:10 PM Andrea Faulds wrote: > Hi, > > Philipp Tanlak wrote: > > I like to elaborate on Nikitas response: I don't think a mb_str_contains > is > > necessary, because the proposed function does not behave differently, if > > the input strings are multibyte strings. > > This

Re: [PHP-DEV] Proposal for a new basic function: str_contains

2020-03-02 Thread Andrea Faulds
Hi, Philipp Tanlak wrote: I like to elaborate on Nikitas response: I don't think a mb_str_contains is necessary, because the proposed function does not behave differently, if the input strings are multibyte strings. This is not true for all character encodings. For UTF-8 it is correct, but

[PHP-DEV] Re: [RFC] token_get_all() TOKEN_AS_OBJECT mode

2020-03-02 Thread Nikita Popov
On Thu, Feb 13, 2020 at 10:47 AM Nikita Popov wrote: > Hi internals, > > This has been discussed a while ago already, now as a proper proposal: > https://wiki.php.net/rfc/token_as_object > > tl;dr is that it allows you to get token_get_all() output as an array of > PhpToken objects. This reduces

[PHP-DEV] Re: [RFC] Userspace operator overloading

2020-03-02 Thread Terje Slettebø
On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote: How many of you would prefer a interface solution for operator overloading? I wonder if the RFC voting should include the option to choose between either the magic method approach (with the syntax proposed in the current RFC version) or using

Re: [PHP-DEV] Re: [RFC] Userspace operator overloading

2020-03-02 Thread Mike Schinkel
> On Mar 2, 2020, at 9:30 AM, Nikita Popov wrote: > > On Thu, Feb 27, 2020 at 9:43 PM wrote: > >> I have changed the proposed names for the bitshift handlers to '__lshift' >> and '__rshift' (instead of __sl and __sr) to make more clear what operator >> is handled by the method (also the method

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Rowan Tommins
On Mon, 2 Mar 2020 at 14:46, Marco Pivetta wrote: > > The code above is NOT going to pass a code review. > It may not pass a code review *from you*, but I don't think your high standards are a good benchmark for the way PHP is used throughout the world. Let's put it this way: if my RFC

Re: [PHP-DEV] Re: [RFC] Userspace operator overloading

2020-03-02 Thread Rowan Tommins
On Mon, 2 Mar 2020 at 14:30, Nikita Popov wrote: > > I think others have already expanded on why it's not possible to group > operators in a meaningful way. The DateTime example is probably the most > pertinent there, in that DateTime + DateTime is illegal, while DateTime - > DateTime is legal.

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Marco Pivetta
Hey Rowan, On Mon, Mar 2, 2020 at 3:39 PM Rowan Tommins wrote: > Hi Marco, > > On Mon, 2 Mar 2020 at 14:00, Marco Pivetta wrote: > > > > > Overall against the RFC: `++` and `--` (prefix and suffix) are supposed > to > > be used with numeric values, not with other types, as that makes >

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Christian Schneider
Am 02.03.2020 um 15:00 schrieb Marco Pivetta : > Overall against the RFC: `++` and `--` (prefix and suffix) are supposed to > be used with numeric values, not with other types, as that makes everything > only more confusing. > > Code written (intentionally) to use `++` and `--` against

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Rowan Tommins
Hi Marco, On Mon, 2 Mar 2020 at 14:00, Marco Pivetta wrote: > > Overall against the RFC: `++` and `--` (prefix and suffix) are supposed to > be used with numeric values, not with other types, as that makes everything > only more confusing. > While I'm generally sympathetic to that principle,

Re: [PHP-DEV] Re: [RFC] Userspace operator overloading

2020-03-02 Thread Nikita Popov
On Thu, Feb 27, 2020 at 9:43 PM wrote: > On 15/02/2020 22:05, jan.h.boeh...@gmx.de wrote: > > Hi internals, > > > > based on the discussions here (https://externals.io/message/108300) and > here > > (https://github.com/php/php-src/pull/5156), I have created a proper RFC > for > > userspace

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Mark Randall
On 02/03/2020 14:08, Rowan Tommins wrote: The problem with this kind of behaviour change is that there's no way for PHP to know whether a particular piece of code has been changed to expect the new behaviour or not Lump it in with editions maybe? -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Rowan Tommins
Hi Alexandru, On 2 March 2020 09:22:57 GMT+00:00, "Alexandru Pătrănescu" wrote: >For point 1 and 2, both the old and new behavior is silent. Can we >think of >a safer way to migrate? That's a very good question, and one I don't have a particularly good answer to. The problem with this kind of

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Marco Pivetta
Hey Rowan, Overall against the RFC: `++` and `--` (prefix and suffix) are supposed to be used with numeric values, not with other types, as that makes everything only more confusing. Code written (intentionally) to use `++` and `--` against non-numeric values should **NOT** pass a code review,

Re: [PHP-DEV] [RFC] Increment/Decrement Fixes

2020-03-02 Thread Alexandru Pătrănescu
Hi Rowan, Thank you for the effort, very good unification of behavior across increment and decrement operations. I would say that all 3 points are most probably code issues and potential bugs. I agree with all of them. For point 3, the new behavior is an error. The problem will be caught earlier

[PHP-DEV] [RFC] [VOTE] str_contains

2020-03-02 Thread Philipp Tanlak
Hello internals! As of today, two weeks have passed since the creation and discussion on the str_contains RFC, without any major controversy. That's why I've updated the RFC status to "Voting". So feel free to submit your vote. The vote requires a 2/3 majority to be accepted and will end in two