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

[Joe Watkins]

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 problems, I chose (a year ago) to
start here; Simply raising the bar simplifies the rules we currently have
and so simplifies their reform (in detail and process).

I'm not following your logic for further delaying voting on this RFC, in
fact I don't see any logic, just an assertion ;)

Cheers
Joe

On Thu, Jul 12, 2018 at 2:22 AM, Sara Golemon  wrote:

> 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 someone chosing to vote Yes at the last minute.
> >
> I can buy that argument, but since there IS room to disagree, then
> such should be spelled out clearly in the voting update RFC.  Let's
> decide and not leave it to subjective interpretation.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Sara Golemon]

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 someone chosing to vote Yes at the last minute.
>
I can buy that argument, but since there IS room to disagree, then
such should be spelled out clearly in the voting update RFC.  Let's
decide and not leave it to subjective interpretation.

-Sara

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

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

[Andrea Faulds]

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. 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 someone chosing to vote Yes at the last minute.


--
Andrea Faulds
https://ajf.me/

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

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

[Andrea Faulds]

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 because we already made same mistake.

Regards,
CHU Zhaowei



Hmm. Returning null with no warning makes perfect sense for keys, since 
null is not a valid key so there's no ambiguity, but for values it seems 
problematic. On that ground I've decided to change my vote to No for the 
value functions, but keep the vote for Yes for the key functions. 
Someone who wants such behaviour could always do 
($array[array_key_last($array)] ?? null), I guess.


--
Andrea Faulds
https://ajf.me/

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

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

[Stanislav Malyshev]

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 idea.

-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Sara Golemon]

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 php-ng pretty did anyway).  I know there
was concern about those two having to merge, and I know I fell on the
side of the one that was developed more publicly, but it still seems
like a no-brainer to me.

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

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

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

[Christoph M. Becker]

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 looks like it will pass.
>>>
>>> I wonder what the RFC author (Enno W) thinks about that approach?
>>
>> This already has been discussed weeks ago, see
>> .
> 
> This was not discussed, it was discarded. Enormous difference.

Well, there was some discussion.  Particularly noteworthy, was Rowan's
post[1] which pointed out that the behavior of list is *undocumented*,
and Larry's post[2] which strongly advises against “multi-returns”.

And finally, as I understand it, the actual proposal that is put to vote
is what the RFC *author* wants to propose.  There is no strict necessity
to deal with any suggestion for improvement.  After all, it's up to the
voters whether a particular RFC will be accepted or rejected.  If
anybody dislikes a certain RFC, they are free to point out their
concerns, and to vote against the RFC.  Period.

[1] 
[2] 

-- 
Christoph M. Becker

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

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

[Christoph M. Becker]

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 myself soon, but it would be super-awesome if
> somebody did.

See 
and particularly .

-- 
Christoph M. Becker



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

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

[Zeev Suraski]

> -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 
> 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 ...


Last year I worked on a bigger rework of our voting rules that tackles this, 
among other topics - given the many deficiencies of the original Voting RFC 
(which was hastily drafted, approved with virtually zero discussion, and yet 
has been considered as some sort of constitution ever since).  I admit I didn't 
have the mental strength to bring it up for discussion but 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.

I think it would make sense to start discussing that (as well as the 
abolish-narrow-margins RFC along with it if you prefer to put it to a vote) as 
soon as we're done with the 7.3 contents, and in preparation for 7.4/8.0 (i.e. 
around the September/October timeframe).  We could of course start discussing 
it sooner, but at least I don't think it makes sense to vote on either of these 
right now.

Zeev


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

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

[Paul Jones]

> 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 (possibly
>> because it was sidetracked); If there are no objections I'll bring it to
>> vote in the coming days ...

Since you brought it up ...

> "The current political climate of Earth

It's probably less "Earth" and more "Western civilization."

> votes that are won by narrow margins build resentment among voters

Well, certainly among some. I have to wonder if this is a reference to the 
author's favored political outcomes being thwarted.

> can lead to instability in the ecosphere

The "ecosphere" of Earth? That's an interesting assertion. I wonder if it's 
true.

> and could be considered harmful to democracy.

There's a long list of things that "could be considered harmful to democracy."

In any case, are we turning this list into a political forum? Because I for one 
can do without it here. I find it in plenty of other places.

I don't have any more to say on that aspect of this topic right now, unless and 
until someone else here sees fit to continue it -- in which case, I'll be happy 
to respond.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php





-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




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

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

[Enno Woortmann]

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 in userland, at least not the ones that get
the last key and/or value of the array. You either need to make a copy
or traverse through the whole array.


With the problem I didn't aim at the problem this RFC tries to solve. I 
think everyone participating in the discussions in the mailing list 
understood the problem of non efficient userland implementations.


I aimed at the issue which lead to the gap between our implementation 
approaches: the indistinguishability between a correct function call 
which returns null and an invalid call with either an empty array or a 
non array value.
As this is an existing problem I still think we should find a common 
solution (which can't be part of this RFC's scope) instead of bringing 
up new function signature patterns for new functions.



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

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

[Levi Morrison]

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, but not 100%. I think there are two
> kinds of changes - one kind is more fundamental than the other. I.e., if
> we add a major feature to the language (like strict type checks, for
> example) it is going to have major influence on the language and
> virtually everybody using it. You can't just ignore it. This also goes
> to changes which alter ways that the syntax works, etc. which have
> potential to break existing code (even if it's bad code, still).
>
> Then there are more "neutral" changes - like adding an utility function
> or an option to a function. PHP has a lot of "syntax sugar" functions
> and sometimes even "kitchen sink" functions - ones that most people
> don't use but some do. Having one more would not be that big of a deal -
> that's where, unlike the above, "what you don't use doesn't hurt you" is
> true.
>
> You probably have guessed already what I am getting at - the second kind
> is probably OK to have 50%+1, since people that don't need this
> option/function can vote no but still we can have it if more people do.
> The counter-argument could be that people that don't need it can just
> avoid voting, but then we don't have clear boundary between "I don't
> think it's useful for enough people to add it" and "I am on vacation and
> haven't bothered to even have an opinion".

If it's a utility function and somehow ~49% of voters oppose it...
think about that. It's 49% objectionable! I don't think that should
pass, not even for a utility function people.

> 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 myself soon, but it would be super-awesome if
> somebody did.

I did this analysis in the past. There are very few RFCs that passed
in this window between 50%+1 and 2/3, but there are a few. The
array_key_first/last RFC is on track to pass in this region.

> P.S. The question of quorum is interesting to explore, though I am not
> sure how we figure out the numbers.

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

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

[Levi Morrison]

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 =
> >> fancyFunction($someInput);
> > But this isn't true even for the array_value_* functions. There must
> > be pre or post processing because of error conditions. This was
> > pointed out by myself and others, but it was still ignored.
> >
> > This is what I mean by discarded, not discussed.
>
> In my eyes being aware of what I put into a function and thus catching
> non array inputs and empty inputs before differs a lot from post
> processing return values as it increases the comprehensibility of the
> code. I also can think of cases where the input format is known and no
> further checks are required.
>
> Additionally the tuple return pattern is not common among the PHP core
> functions and I don't know many occurences of this pattern in userland
> PHP code neither at the companies I've worked at nor at open source
> software/frameworks (correct me if I'm wrong) except the by far outdated
> old foreach construct with reset() and each(), thus I assume it's not a
> that common pattern for PHP developers to use it in core functions.
>
> As I pointed out during the discussion we should also watch at existing
> functions with the same problem, differ between a valid return value and
> an error.
> Not all of them can be changed to use different return mechanisms like
> the tuple return pattern (eg. array_pop).
>
> Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later
> stage to not return null in error cases but instead throw an
> InvalidArgumentException or something like that (at least for function
> calls with an empty array for functions which require a filled array,
> for invalid types maybe a fatal TypeError like it's thrown when a type
> hinted argument in a userland function is violated is the correct
> choice). Would be a pretty large BC breaking change but it would be
> consistent among the array functions.
>
> 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 in userland, at least not the ones that get
the last key and/or value of the array. You either need to make a copy
or traverse through the whole array. I have been working to solve this
by making a bidirectional array iterator that can start at either end
of the array and can traverse back and forth. This work will not ready
for 7.3, not even with the extension to the feature freeze because
there is some design that needs to happen; the work I have so far is
here:


https://github.com/php/php-src/compare/master...morrisonlevi:BidirectionalArrayIterator

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

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

[Stanislav Malyshev]

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 fundamental than the other. I.e., if
we add a major feature to the language (like strict type checks, for
example) it is going to have major influence on the language and
virtually everybody using it. You can't just ignore it. This also goes
to changes which alter ways that the syntax works, etc. which have
potential to break existing code (even if it's bad code, still).

Then there are more "neutral" changes - like adding an utility function
or an option to a function. PHP has a lot of "syntax sugar" functions
and sometimes even "kitchen sink" functions - ones that most people
don't use but some do. Having one more would not be that big of a deal -
that's where, unlike the above, "what you don't use doesn't hurt you" is
true.

You probably have guessed already what I am getting at - the second kind
is probably OK to have 50%+1, since people that don't need this
option/function can vote no but still we can have it if more people do.
The counter-argument could be that people that don't need it can just
avoid voting, but then we don't have clear boundary between "I don't
think it's useful for enough people to add it" and "I am on vacation and
haven't bothered to even have an opinion".

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 myself soon, but it would be super-awesome if
somebody did.

P.S. The question of quorum is interesting to explore, though I am not
sure how we figure out the numbers.
-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Woortmann, Enno]

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 must
be pre or post processing because of error conditions. This was
pointed out by myself and others, but it was still ignored.

This is what I mean by discarded, not discussed.


In my eyes being aware of what I put into a function and thus catching 
non array inputs and empty inputs before differs a lot from post 
processing return values as it increases the comprehensibility of the 
code. I also can think of cases where the input format is known and no 
further checks are required.


Additionally the tuple return pattern is not common among the PHP core 
functions and I don't know many occurences of this pattern in userland 
PHP code neither at the companies I've worked at nor at open source 
software/frameworks (correct me if I'm wrong) except the by far outdated 
old foreach construct with reset() and each(), thus I assume it's not a 
that common pattern for PHP developers to use it in core functions.


As I pointed out during the discussion we should also watch at existing 
functions with the same problem, differ between a valid return value and 
an error.
Not all of them can be changed to use different return mechanisms like 
the tuple return pattern (eg. array_pop).


Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later 
stage to not return null in error cases but instead throw an 
InvalidArgumentException or something like that (at least for function 
calls with an empty array for functions which require a filled array, 
for invalid types maybe a fatal TypeError like it's thrown when a type 
hinted argument in a userland function is violated is the correct 
choice). Would be a pretty large BC breaking change but it would be 
consistent among the array functions.


In my opinion neither rejecting the RFC nor changing it to return tuples 
solves the underlying problem.


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

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

[Sara Golemon]

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 I'll bring it to
> vote in the coming days ...
>
"The current political climate of Earth shows us that votes that are
won by narrow margins build resentment among voters, can lead to
instability in the ecosphere, and could be considered harmful to
democracy."

Snicker... I want to vote for this purely to make that sentence part
of our bylaws.

In all seriousness though, I'm in favor of this.  66.666% isn't an
unreasonable bar.  If you can't get 2 out of 3 people to think your
idea makes sense, then it might need work.

-Sara

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

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

[Niklas Keller]

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] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Colin O'Dell]

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 rushed through without
properly addressing some of the outstanding issues and alternate
implementation ideas that have been raised.  The only revisions to the RFC
were the inclusion of the two value-related functions.  IMHO, any RFC going
to vote despite known "opposition" or requested changes should at least
contain a summary of those points and counter-points, but if feels like
those are being ignored here.

So while I do understand the value of such a feature, I'd much rather delay
its implementation than to rush it along with potential issues and no
strong consensus.

Respectfully,

Colin O'Dell
colinod...@gmail.com
https://www.colinodell.com

[PHP-DEV] [RFC] abolish narrow margins

[Joe Watkins]

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 ...

Cheers
Joe

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

[Levi Morrison]

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:
> > >>
> > >>> 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
> >  notice/warning,
> >  is wrong IMO. I know we already do this in other array_* functions,
> >  but we
> >  cannot keep making mistakes just because we already made same mistake.
> > 
> > >>> I voted no for the same reason. I'd even say that introducing a new
> > >>> array_
> > >>> function that still accepts non arrays just to return null with a
> > >>> warning
> > >>> doesn't make sense at this point.
> > >>>
> > >>> With that said, I'd gladly vote yes if there would be a way to
> > >>> distinguish
> > >>> array_value_first([]) from array_value_first([0 => null]).
> > >>>
> > >>> Regards,
> > >>> Pedro
> > >> To safely use it a call to empty or count or something needs to happen:
> > >>
> > >>  if (!empty($array)) {
> > >>  $value = array_value_first($array);
> > >>  // do something with $value
> > >>  }
> > >>
> > >> This is okay, but not great. Compare that to the design that returns a
> > >> tuple though:
> > >>
> > >>  if ([$_, $value] = array_first($array)) {
> > >>  // do something with $value
> > >>  }
> > >>
> > >> People who argue against the tuple because they don't like the design
> > >> need to consider the bigger picture. The tuple way is less code,
> > >> serves more use cases with fewer functions, and I even [implemented
> > >> it][1]. If the array destructuring behavior seems unclear we can
> > >> simply put an example in the manual pages for these functions --
> > >> problem solved.
> > >>
> > >> This is not how RFC feedback should be handled. I hope more people
> > >> vote no so we can reject this do it properly.
> > >>
> > > I do like this approach with two functions array_first & array_last
> > > returning
> > > a tuple. However, voting is  underway and it looks like it will pass.
> > >
> > > I wonder what the RFC author (Enno W) thinks about that approach?
> >
> > This already has been discussed weeks ago, see
> > .
> >
> > --
> > Christoph M. Becker
>
> This was not discussed, it was discarded. Enormous difference.

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 must
be pre or post processing because of error conditions. This was
pointed out by myself and others, but it was still ignored.

This is what I mean by discarded, not discussed.

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

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

[Levi Morrison]

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:
> >>>
>  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 because we already made same mistake.
> 
> >>> I voted no for the same reason. I'd even say that introducing a new
> >>> array_
> >>> function that still accepts non arrays just to return null with a
> >>> warning
> >>> doesn't make sense at this point.
> >>>
> >>> With that said, I'd gladly vote yes if there would be a way to
> >>> distinguish
> >>> array_value_first([]) from array_value_first([0 => null]).
> >>>
> >>> Regards,
> >>> Pedro
> >> To safely use it a call to empty or count or something needs to happen:
> >>
> >>  if (!empty($array)) {
> >>  $value = array_value_first($array);
> >>  // do something with $value
> >>  }
> >>
> >> This is okay, but not great. Compare that to the design that returns a
> >> tuple though:
> >>
> >>  if ([$_, $value] = array_first($array)) {
> >>  // do something with $value
> >>  }
> >>
> >> People who argue against the tuple because they don't like the design
> >> need to consider the bigger picture. The tuple way is less code,
> >> serves more use cases with fewer functions, and I even [implemented
> >> it][1]. If the array destructuring behavior seems unclear we can
> >> simply put an example in the manual pages for these functions --
> >> problem solved.
> >>
> >> This is not how RFC feedback should be handled. I hope more people
> >> vote no so we can reject this do it properly.
> >>
> > I do like this approach with two functions array_first & array_last
> > returning
> > a tuple. However, voting is  underway and it looks like it will pass.
> >
> > I wonder what the RFC author (Enno W) thinks about that approach?
>
> This already has been discussed weeks ago, see
> .
>
> --
> Christoph M. Becker

This was not discussed, it was discarded. Enormous difference.

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

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

[Christoph M. Becker]

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 timetable in the Wiki:
.

-- 
Christoph M. Becker

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

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

[Björn Larsson]

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 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 because we already made same mistake.


I voted no for the same reason. I'd even say that introducing a new
array_
function that still accepts non arrays just to return null with a
warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to
distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro

To safely use it a call to empty or count or something needs to happen:

  if (!empty($array)) {
  $value = array_value_first($array);
  // do something with $value
  }

This is okay, but not great. Compare that to the design that returns a
tuple though:

  if ([$_, $value] = array_first($array)) {
  // do something with $value
  }

People who argue against the tuple because they don't like the design
need to consider the bigger picture. The tuple way is less code,
serves more use cases with fewer functions, and I even [implemented
it][1]. If the array destructuring behavior seems unclear we can
simply put an example in the manual pages for these functions --
problem solved.

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.


I do like this approach with two functions array_first & array_last
returning
a tuple. However, voting is  underway and it looks like it will pass.

I wonder what the RFC author (Enno W) thinks about that approach?

This already has been discussed weeks ago, see
.


Aha, tnx.

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

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

[Côme Chilliet]

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 case is
> not a bad thing.

The point of these functions is to avoid complicated hard to read code for 
simple operations.
This if is hard to read for me and not much better that 
array_values(some_function())[0].

Côme

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

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

[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 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 because we already made same mistake.

>>> I voted no for the same reason. I'd even say that introducing a new
>>> array_
>>> function that still accepts non arrays just to return null with a
>>> warning
>>> doesn't make sense at this point.
>>>
>>> With that said, I'd gladly vote yes if there would be a way to
>>> distinguish
>>> array_value_first([]) from array_value_first([0 => null]).
>>>
>>> Regards,
>>> Pedro
>> To safely use it a call to empty or count or something needs to happen:
>>
>>  if (!empty($array)) {
>>  $value = array_value_first($array);
>>  // do something with $value
>>  }
>>
>> This is okay, but not great. Compare that to the design that returns a
>> tuple though:
>>
>>  if ([$_, $value] = array_first($array)) {
>>  // do something with $value
>>  }
>>
>> People who argue against the tuple because they don't like the design
>> need to consider the bigger picture. The tuple way is less code,
>> serves more use cases with fewer functions, and I even [implemented
>> it][1]. If the array destructuring behavior seems unclear we can
>> simply put an example in the manual pages for these functions --
>> problem solved.
>>
>> This is not how RFC feedback should be handled. I hope more people
>> vote no so we can reject this do it properly.
>>
> I do like this approach with two functions array_first & array_last
> returning
> a tuple. However, voting is  underway and it looks like it will pass.
> 
> I wonder what the RFC author (Enno W) thinks about that approach?

This already has been discussed weeks ago, see
.

-- 
Christoph M. Becker

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

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

[Björn Larsson]

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 notice/warning,
is wrong IMO. I know we already do this in other array_* functions, but we
cannot keep making mistakes just because we already made same mistake.


I voted no for the same reason. I'd even say that introducing a new array_
function that still accepts non arrays just to return null with a warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro

To safely use it a call to empty or count or something needs to happen:

 if (!empty($array)) {
 $value = array_value_first($array);
 // do something with $value
 }

This is okay, but not great. Compare that to the design that returns a
tuple though:

 if ([$_, $value] = array_first($array)) {
 // do something with $value
 }

People who argue against the tuple because they don't like the design
need to consider the bigger picture. The tuple way is less code,
serves more use cases with fewer functions, and I even [implemented
it][1]. If the array destructuring behavior seems unclear we can
simply put an example in the manual pages for these functions --
problem solved.

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.

I do like this approach with two functions array_first & array_last 
returning

a tuple. However, voting is  underway and it looks like it will pass.

I wonder what the RFC author (Enno W) thinks about that approach?

r//Björn Larsson

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

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

[Sara Golemon]

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 seems the only
> reason it's not being voted on is because people don't want them to.
>
Well... it's not being voted on because, despite being six days till
the originally planned feature freeze date, neither sponsor has opened
a vote.

-Sara

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

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

[Zeev Suraski]

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 seems the only
> reason it's not being voted on is because people don't want them to.
>

The only time I've heard about this was slightly under 3 weeks ago when
Nikita sent this RFC to internals - where he himself alluded to the fact
that this is "a large and complex proposal that may not be able to make the
deadline".  To be clear, introducing such an RFC for discussion (a large
and complex one) after alphas have been released as opposed to months
before alphas are released constitutes as 'rushed' in my book, and
apparently in the books of others as well.  You don't have to agree of
course as we're all obviously entitled to our own opinions...

Zeev

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

[Levi Morrison]

> 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 don't want them to.

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

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

[Zeev Suraski]

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 elsewhere. I want to personally
> affirm that Nikita and Bob have been working hard on this for a long
> time. This is not a last minute change being rushed. They have been
> quite thorough and have discovered and fixed many edge cases that I
> suspect other authors would not have found or would have ignored. Yes,
> it is being voted on in the narrow gap between first alphas and
> feature freeze but that does not mean it is rushed.
>

It is being rushed as far as the RFC process & discussions around it are
concerned - that's what I meant.  I did not dispute for a second that the
patch looks thoroughly thought out and a lot of effort went into it - it's
very evident and I acknowledged it already.

Zeev

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

[Marco Pivetta]

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 elsewhere. I want to personally
> affirm that Nikita and Bob have been working hard on this for a long
> time. This is not a last minute change being rushed. They have been
> quite thorough and have discovered and fixed many edge cases that I
> suspect other authors would not have found or would have ignored. Yes,
> it is being voted on in the narrow gap between first alphas and
> feature freeze but that does not mean it is rushed.


Ack, and it is such a massive improvement that pushing it back now would
simply delay a very huge jump (forward) in ecosystem quality at large for
more than a year.

Bob and Nikita got it right, they made something well thought out, well
tested, and previously already discussed: give the vote a chance, add a
sub-vote for which version to target, if required.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[Levi Morrison]

> 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 working hard on this for a long
time. This is not a last minute change being rushed. They have been
quite thorough and have discovered and fixed many edge cases that I
suspect other authors would not have found or would have ignored. Yes,
it is being voted on in the narrow gap between first alphas and
feature freeze but that does not mean it is rushed.

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

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

[Levi Morrison]

> 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 error. So I have to add 
> more code to handle this special case while I do not need any with 
> array_first_value.

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 case is
not a bad thing.

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

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

[Jan Ehrhardt]

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
>https://github.com/php/pecl-mail-mailparse/blob/master/mailparse.c#L1466

For anyone interested: it segfaults on Windows and Linux. No explication
yet:
https://github.com/php/pecl-mail-mailparse/pull/5#issuecomment-403990392
and following comments by Remi.
-- 
Jan

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

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

[Christoph M. Becker]

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 be about ready for voting.
> 
> Even if the RMs decide that this cannot go into PHP 7.3, we'd still like to
> start voting on this RFC soon (in the next few days).

After consulting with other release managers, I would ask you not to
target PHP 7.3, because we're already in alpha stage, the changes for
feature are quite comprehensive, and affect extensions in a subtle way[1]:

| The other are changes to reference assignments. These are not
| necessary to build against PHP 7.3, but are needed to ensure the
| behavior is fully correct.

[1] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Unifying logical operators

[Rowan Collins]

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 updating" and "having to run
a static analysis tool and carefully read its results to stop your code
having a subtly different behaviour".

Introducing new errors is nearly always better than silently changing
behaviour (this is the entire principle of run-time type checks, after all).




> On Tue, Jul 10, 2018 at 5:01 AM, Rowan Collins 
> wrote:
> > As your own next example demonstrates, it does rely on the difference in
> > precedence, because without it, you could only use this idiom after
> > carefully checking that the left-hand side would be evaluated in one go,
> > and probably using an extra set of parentheses.
> >
>
> The defined or die idiom does not depend on precedence, because it doesn't
> contain an assignment operator.  One could theoretically do
> $isDefined=defined("X") or die() - however that would be pointless as
> $isDefined would always be true.
>


Right, which is why I said your *next* example, which did use assignment.
The point is that *reliably using the idiom* requires a specific
precedence, so that you don't have to carefully vet which other operators
are involved in the expression.




> > While I've not seen it used much in PHP code, the "do this or die" idiom
> > is common in Perl (which also has post-fix "if" and "unless" modifiers,
> so
> > those are a different feature again).
> >
>
> Forgive my lack of knowledge with perl, but it looks[1] like they only
> support a postfix if and postfix unless operators - which can serve the
> same purpose as PHP's and/or (x and y => y if x, x or y => y unless !x).
>

Perhaps I worded that badly. I was saying two things:

- The "do or die" idiom is extremely common in Perl. Just searching the
documentation should be enough to convince you of that:
https://duckduckgo.com/?q=site%3Aperldoc.perl.org+"or+die;
- Perl *also* has post-fix if and unless operators, which you had mentioned
in Ruby (Ruby inherited a lot from Perl). Clearly, people don't see these
as a better replacement for the use of "or".




> My thought for aliasing is that it may help with legacy code (if you're not
> relying on the return value, which is 99% of cases), as well as there being
> no symbolic equivalent for xor (as you state below it's not equivalent to
> != as I thought)
>


Just to reiterate, I strongly feel that aliasing is not an option. If the
aim is to reduce confusion, having the same code give different results in
different PHP versions is a massive own goal.




> On Tue, Jul 10, 2018 at 2:37 PM, Kalle Sommer Nielsen 
> wrote:
>
> >
> > I personally wanted to extend this syntax but I never got around to it
> > to support: "do() or throw new Exception(...);", tho its just a code
> > style over: "if(!do()){ throw new Exception(...); }"
> >
>
> do() or throw doesn't actually work because throw is a language construct,
> not a function.
>


Yes, hence "wanted to extend this syntax" - the suggestion is that this
would be a useful feature to add, not one that already exists.




> > A more readable syntax, if we were designing from scratch, might be to
> > look at SmallTalk, where ifTrue and ifFalse are methods on the boolean
> > class, so can appear post-fix after any boolean, giving you something
> like:
> >
> > $connected ifFalse: die();
> >
>
> I hesitate to propose adding a new syntax to PHP, especially for something
> so rarely used it makes me question if it's truly necessary.  If anything I
> would think we should prefer a syntax that we can point to other languages
> as examples (like the if/unless syntax from Ruby).  It feels odd to clean
> up a rarely used operator by replacing it with fresh syntactical sugar.
>


I agree that adding new syntax is unnecessary for this, but since you keep
mentioning the postfix if/unless which Ruby inherited from Perl, I thought
I'd point to another language we could borrow syntax from, which is
actually closer to the current idiom ("condition keyword action", not
"action keyword condition").


Regards,
-- 
Rowan Collins
[IMSoP]

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

[Zeev Suraski]

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
> exciting thing to improve between now and 2020.  I know some people have
> plans
> they're already working on.
>

We can agree to disagree, but effectively turning PHP into an
optionally-typed language - which Nikita's patch does a HUGE step towards
(IMHO a much bigger one than scalar type hints did at the time) is more or
less a singular event.
And no, I'm absolutely not encouraging us to come up with additional
language-changing features just for the sake of marketing - there's a world
of difference between timing the rollout schedule of what we intend to roll
out anyway, and adding extra bells and whistles just to make the new
version attractive.

Conceptually, as Nicolas and you have both hinted at, PHP 7.x is the series
> where "typing got real".  From a user-facing/marketing perspective 7.x is
> all
> about performance and typing.  That's the through line.  Including typed
> properties in that makes logical sense, marketing-wise, and would be a
> fitting
> capstone to the 7.x series in that regard.
>

I didn't hint at that, at least not intentionally (I'd say 90-95% of the
feedback I've seen for PHP 7 was about performance, and 5-10% was pretty
much everything else, but that's beside the point).
What's on point is that new or improved capabilities are the draw into new
versions.  The more (sensible!) of those you have, the better.  Wasting our
'ammo' on the 7.x line at this point is, IMHO, a mistake.  I guess I have
much higher levels of self control and patience - as this is precisely what
we're not going to do with the stuff we've been working on (JIT, FFI, and
phpng in the past).


> However, mixing "no new features in 7.4/8.0, just the engine changes" with
> "we
>
need a big showy thing in 8.0 to help sell it", er, feels like a
> contradiction.


Maybe it feels that way, but it really isn't.  I'm not sure whether you've
had the luxury of contributing to the PHP engine, but working on two
simultaneous active branches with substantial data structure differences is
an unholy mess (it's also way, way worse than working on two branches of an
average PHP project).   Even if all of the developers are focused on PHP 8
it's going to be a remarkably difficult feat to achieve.  Throwing in
another parallel version that we'll need to work on at the same time is
shooting ourselves in the foot.

It makes it sound more like "borrowing" a feature from 7.3
> (typed properties) for 8.0 for purely marketing purposes, and then also
> blocking any other features, so that we know 2 years out "the only
> interesting
> thing in 8.x will be typed properties, because that was written when 8.x
> was
> still just a twinkle in the eye but we sat on it".  That feels very
> disingenuous.
>

Please don't put words in my mouth and then call them disingenuous :)
I did not say we should 'block any other features'.  In fact, in my
blueprint for PHP 8 - I said it's clear to me we're likely to see
additional ideas that will be proposed for PHP 8.  It's an extra feature
release that will divide our resources that I'm arguing against.

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.
2.  We should not have a 7.4 that divides our resources(*);  Much like with
5.6 -> 7.0, we should focus on one feature version at a time.
3.  We're better off saving Typed Properties for 8.0 as another draw - and
we can also make it better by that timeline (a comprehensive typing
solution, and not an incremental one).

I am sure that's not your intent but those two statements together
> ("minimize
> features for 8.0" and "save this feature for 8.0 for marketing") just
> don't
> fit together in my mind in a nice way.
>

Where did I say we should minimize features for 8.0?

Zeev

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

[Côme Chilliet]

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 array_first_value was because I was using it on a 
function return to do something with it.

Like:
if (array_first_value(some_function()) > 3) {
  // do something
}

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 error. So I have to add 
more code to handle this special case while I do not need any with 
array_first_value.

Côme

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

[Côme Chilliet]

> $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 understand why you split comparison and equality, 
as I understood it at first the point was exactly to be able to have ordering 
equality without having value equality. If this leads to strangeness, why allow 
it?

Côme


signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] Unifying logical operators

[Andrey Andreev]

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 deprecation would make literally all of my code output
>> entire screens of warnings.
>>
>
> $foo=$foo??"bar"; would work there.  I could definitely see this being an
> issue if you weren't using isset (although a concrete example of that
> doesn't come to mind right away).
>

I'm very well aware of the alternatives, that's not the point. I and
although not a majority, many others too would have to go and replace
countless instances of OR usage, for no reason other than "it can be
done another way".

Aside from a few people asking what the difference is, in more than a
decade with PHP, I've never seen a single person who's had a problem
with the operators you want to deprecate. They're not a common cause
for bugs even by a long shot, nor a common annoyance, so I fail to see
the benefits of your proposal.

Cheers,
Andrey.

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