Re: [PHP-DEV] Unifying logical operators

Hi, On Wed, Jul 11, 2018 at 5:20 AM, Ryan wrote: > On Tue, Jul 10, 2018 at 2:58 PM, Andrey Andreev wrote: > >> isset($foo) OR $foo = 'bar'; (and similar variations using empty() >> and/or &&) is another pattern I use often to set fallback values for >> empty or missing inputs. >> >> An eventual

Re: [PHP-DEV] [RFC] Typed Properties

On Tue, Jul 10, 2018 at 10:19 PM Larry Garfield wrote: > While the marketing angle is valid, Zeev, it seems predicated on the idea > that > there won't be any other major new-and-cool features developed between now > and > 8.0. I'm reasonably confident that someone will find some user-facing >

Re: [PHP-DEV] Unifying logical operators

On 11 July 2018 at 03:20, Ryan wrote: > > PHP 7 code should never be blindly upgraded to PHP 8 (which is what this > would target for actual changes, not just deprecation/notices). This would > have to be clearly stated in the upgrade guide. > There's a big difference between "not blindly

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

Le mardi 10 juillet 2018, 18:41:17 CEST Levi Morrison a écrit : > People who argue against the tuple because they don't like the design > need to consider the bigger picture. My guess is people arguing for the tuple do not understand the usecase :-) Each time I felt the need for

Re: [PHP-DEV] [RFC] [VOTE] User-defined object comparison

> $x->__equals($y) && $y->__equals($z) requires that $x->__compareTo($z) be > *TRUE*. Typo here, it should be __equals at the end not __compareTo. > In fact, returning 0 in __compareTo for undefined natural ordering leads to > all kinds of strange behaviour If this is the case, I do not

Re: [PHP-DEV] [RFC] Typed Properties

On Wed, Jul 11, 2018 at 5:44 PM Levi Morrison wrote: > > It is being rushed as far as the RFC process & discussions around it are > concerned - that's what I meant. > > I do not agree with this either. This has been previously discussed, > they have given it an ample discussion period, and it

Re: [PHP-DEV] [RFC] Typed Properties

> It is being rushed as far as the RFC process & discussions around it are > concerned - that's what I meant. I do not agree with this either. This has been previously discussed, they have given it an ample discussion period, and it seems the only reason it's not being voted on is because people

Re: [PHP-DEV] [RFC] Typed Properties

On Wed, Jul 11, 2018 at 10:43 AM, Levi Morrison wrote: >> It is being rushed as far as the RFC process & discussions around it are >> concerned - that's what I meant. > > I do not agree with this either. This has been previously discussed, > they have given it an ample discussion period, and it

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

Den 2018-07-11 kl. 02:41, skrev Levi Morrison: On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote: On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote: I don't think we have an agreement on dealing with non-existing value, and the way this RFC proposed, just returning null without any

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

On 11.07.2018 at 17:19, Björn Larsson wrote: > Den 2018-07-11 kl. 02:41, skrev Levi Morrison: > >> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote: >> >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote: >>> I don't think we have an agreement on dealing with non-existing

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

Le mercredi 11 juillet 2018, 07:37:56 CEST Levi Morrison a écrit : > This is true. For completeness the fix is very mild: > > if (([$_, $value] = array_first(some_function()) && $value > 3) { > // do something > } > > I still think this is better. Forcing you to handle the error

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

Hey, any reason for not having both, resulting in a total of 6 functions? Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

On Wed, Jul 11, 2018 at 12:41 PM, Joe Watkins wrote: > I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote > in the very near future ... > > We discussed it a year ago, and discussion died down to nothing (possibly > because it was sidetracked); If there are no objections

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

On Tue, Jul 10, 2018 at 8:42 PM Levi Morrison wrote: > This is not how RFC feedback should be handled. I hope more people > vote no so we can reject this do it properly. > I agree with the spirit of this RFC but I also agree with Levi. It feels like this particular implementation is being

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

Am 11.07.2018 um 18:20 schrieb Levi Morrison: As an example, it was claimed: If I use a function I expect it to give me a return value which I can use without any further post processing $wantedValue = fancyFunction($someInput); But this isn't true even for the array_value_* functions. There

Re: [PHP-DEV] [RFC] abolish narrow margins

Hi! > We discussed it a year ago, and discussion died down to nothing (possibly > because it was sidetracked); If there are no objections I'll bring it to > vote in the coming days ... I tend to agree with the sentiment, but not 100%. I think there are two kinds of changes - one kind is more

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

On Wed, Jul 11, 2018 at 11:42 AM Woortmann, Enno wrote: > > Am 11.07.2018 um 18:20 schrieb Levi Morrison: > > > As an example, it was claimed: > > > >> If I use a function I expect it to give me a return value which I can > >> use without any further post processing $wantedValue = > >>

Re: [PHP-DEV] [RFC] abolish narrow margins

On Wed, Jul 11, 2018 at 12:19 PM Stanislav Malyshev wrote: > > Hi! > > > We discussed it a year ago, and discussion died down to nothing (possibly > > because it was sidetracked); If there are no objections I'll bring it to > > vote in the coming days ... > > I tend to agree with the sentiment,

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

Am 11.07.2018 um 20:18 schrieb Levi Morrison: In my opinion neither rejecting the RFC nor changing it to return tuples solves the underlying problem. What is the underlying problem in your opinion? My opinion is that the core problem is that these functions cannot be efficiently implemented

Re: [PHP-DEV] [RFC] Typed Properties

On Wed, Jul 11, 2018 at 4:44 PM Levi Morrison wrote: > > My logic is quite simple: > > 1. Something as big as Typed Properties shouldn't be a last minute, > rushed > > RFC. Really - any RFC shouldn't - but in particular major language > changes. > > I have seen this sentiment expressed

[PHP-DEV] Re: libmbfl API changes in PHP 7.3

Jan Ehrhardt in php.internals (Tue, 10 Jul 2018 15:39:39 +0200): >"Christoph M. Becker" in php.internals (Tue, 10 Jul 2018 12:04:10 >+0200): >>Have you tried to convert the first two arguments via mbfl_no2encoding()[1]? > >It compiles, but segfaults in 1 test on this line

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

> Either I know that the array is not empty, or I do not care because NULL will > be ignored correctly. > In the second case, with a tuple I’m stuck because if I do: > > if (array_first(some_function())[1] > 3) { > // do something > } > > If array_first returns NULL this will trigger a PHP

Re: [PHP-DEV] [RFC] Typed Properties

On 10.07.2018 at 12:26, Nikita Popov wrote: > I've just updated the RFC with the last major change (switch to the "no > intrinsic types" alternative for reference handling). Apart from some minor > tweaks (maybe add a bit more information on how the implementation works) > the RFC itself should

Re: [PHP-DEV] [RFC] Typed Properties

On Wed, Jul 11, 2018 at 3:44 PM, Levi Morrison wrote: > > My logic is quite simple: > > 1. Something as big as Typed Properties shouldn't be a last minute, > rushed > > RFC. Really - any RFC shouldn't - but in particular major language > changes. > > I have seen this sentiment expressed

Re: [PHP-DEV] [RFC] Typed Properties

> My logic is quite simple: > 1. Something as big as Typed Properties shouldn't be a last minute, rushed > RFC. Really - any RFC shouldn't - but in particular major language changes. I have seen this sentiment expressed elsewhere. I want to personally affirm that Nikita and Bob have been

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

Den 2018-07-11 kl. 17:27, skrev Christoph M. Becker: On 11.07.2018 at 17:19, Björn Larsson wrote: Den 2018-07-11 kl. 02:41, skrev Levi Morrison: On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote: On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote: I don't think we have an agreement

[PHP-DEV] [RFC] abolish narrow margins

Afternoon internals, I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote in the very near future ... We discussed it a year ago, and discussion died down to nothing (possibly because it was sidetracked); If there are no objections I'll bring it to vote in the coming days

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker wrote: > > On 11.07.2018 at 17:19, Björn Larsson wrote: > > > Den 2018-07-11 kl. 02:41, skrev Levi Morrison: > > > >> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote: > >> > >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote: > >>> >

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

On Wed, Jul 11, 2018 at 10:16 AM Levi Morrison wrote: > > On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker wrote: > > > > On 11.07.2018 at 17:19, Björn Larsson wrote: > > > > > Den 2018-07-11 kl. 02:41, skrev Levi Morrison: > > > > > >> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães wrote:

[PHP-DEV] PHP 7.3 timetable adjustment: additional alpha4

Hi! Due to the large amount of RFCs which have their end of voting set closely to the originally scheduled feature freeze for PHP 7.3, the release managers have decided to insert an additional alpha4 (i.e. to postpone the feature freeze by two weeks to 2018-07-31). You can find the up-to-date

Re: [PHP-DEV] [RFC] abolish narrow margins

> On Jul 11, 2018, at 12:10, Sara Golemon wrote: > > On Wed, Jul 11, 2018 at 12:41 PM, Joe Watkins wrote: >> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote >> in the very near future ... >> >> We discussed it a year ago, and discussion died down to nothing

Re: [PHP-DEV] [RFC] abolish narrow margins

Zeev, > I think our voting rules are in need of a much thorough review than just pushing the limit to 2/3 - which also IMHO doesn't tackle the difference scenarios that exist out there. Agree, they need reform, but rather than trying to discuss and pass a monolithic RFC that tries to solve all

RE: [PHP-DEV] [RFC] abolish narrow margins

> -Original Message- > From: Joe Watkins [mailto:krak...@php.net] > Sent: Wednesday, July 11, 2018 7:41 PM > To: PHP internals > Subject: [PHP-DEV] [RFC] abolish narrow margins > > Afternoon internals, > > I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote in >

Re: [PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

Hi, CHU Zhaowei wrote: I voted no. I don't think we have an agreement on dealing with non-existing value, and the way this RFC proposed, just returning null without any notice/warning, is wrong IMO. I know we already do this in other array_* functions, but we cannot keep making mistakes just

Re: [PHP-DEV] [RFC] abolish narrow margins

On Wed, Jul 11, 2018 at 7:10 PM, Andrea Faulds wrote: > 2/3+1 is silly, though. 2/3 already means there's twice as many agreeing as > disagreeing, having +1 doesn't serve the tie-breaking function there that it > does for 50%+1. But that was indeed a knife-edge RFC, it was actually saved > by

Re: [PHP-DEV] [RFC] abolish narrow margins

Am 11.07.2018 um 20:18 schrieb Stanislav Malyshev: > That said, I'd love to see how many of the accepted RFCs we have now > were actually accepted by margin between 50%+1 and 2/3 and what they > are, if the number is very low maybe it's irrelevant. Unfortunately I > don't have time to do it

Re: [PHP-DEV] [RFC] abolish narrow margins

On Wed, Jul 11, 2018 at 5:12 PM, Christoph M. Becker wrote: > and particularly . > Interesting, better than I'd thought actually. It's odd that the 64bit stuff was the one that was < 2/3rds. iirc the only honestly contentious thing about that was the potential to break existing extensions (which

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()

On 11.07.2018 at 18:16, Levi Morrison wrote: > On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker wrote: >> >> On 11.07.2018 at 17:19, Björn Larsson wrote: >> >>> I do like this approach with two functions array_first & array_last >>> returning >>> a tuple. However, voting is underway and it

Re: [PHP-DEV] [RFC] abolish narrow margins

Hi! > See > and particularly . Ah yes, thanks, I thought I remembered something like that. It's a bit old but still good. Looks like the number of RFCs that would suffer from move to 2/3 is very low, thus I think it's a good

Re: [PHP-DEV] [RFC] abolish narrow margins

Hey Sara, Sara Golemon wrote: I don't remember the specifics about integer semantics (which fell precisely on 2/3 and thus would have failed the +1 check), but again I'll offer than perhaps both needed more discussion, and maybe shouldn't have passed. *shrug* -Sara 2/3+1 is silly, though.