Hey Internals,
I'd like to put the variadic empty() RFC to vote.
RFC: https://wiki.php.net/rfc/variadic_empty
Voting will finish in 14 days time on March 21st.
Voting has now ended with a 26:26 yes/no split. This means the RFC has
has been declined (namely surrounding the ambiguity of what
Le 07/03/2015 12:56, Thomas Punt a écrit :
I'd like to put the variadic empty() RFC to vote.
RFC: https://wiki.php.net/rfc/variadic_empty
Hi,
Discussing this RFC with other people at AFUP, we ended up on the -1
side (by a thin margin).
The main reason given against this proposal was that
Am 13.03.2015 um 09:57 schrieb Matteo Beccati:
On 13/03/2015 07:46, Crypto Compress wrote:
how about two separate methods all_empty() and non[e]_empty()?
How about empty() and full() ?
Ok, that was a bad attempt as a joke, but please no ;)
Hello Matteo,
don't get your point. Are you
On 14/03/2015 07:32, Crypto Compress wrote:
Am 13.03.2015 um 09:57 schrieb Matteo Beccati:
On 13/03/2015 07:46, Crypto Compress wrote:
how about two separate methods all_empty() and non[e]_empty()?
How about empty() and full() ?
Ok, that was a bad attempt as a joke, but please no ;)
Hello
how about two separate methods all_empty() and non[e]_empty()?
How about empty() and full() ?
Ok, that was a bad attempt as a joke, but please no ;)
don't get your point. Are you against my naming suggestions or the
possibility to check many vars on emptiness?
There are these two groups with
Am 12.03.2015 um 20:42 schrieb Thomas Punt:
The only compromise I can think of (though not sure on its feasibility) would be
to have a flag as the last parameter that defaulted to logically AND'ing its
args
with the ability to switch the semantics to logically OR the args.
Hello Thomas,
how
On 13/03/2015 07:46, Crypto Compress wrote:
how about two separate methods all_empty() and non[e]_empty()?
How about empty() and full() ?
Ok, that was a bad attempt as a joke, but please no ;)
Cheers
--
Matteo Beccati
Development Consulting - http://www.beccati.com/
--
PHP Internals -
Hey PHP Internals,
So there hasn't been much discussion on this RFC, and yet a lot of people have
voted -1 on it. This is a little disappointing because I'm not entirely sure why
people are against it - and no one seems to want to debate it either.
From pre-RFC discussions, two main concerns
On Thu, 12 Mar 2015, Thomas Punt wrote:
Hey PHP Internals,
So there hasn't been much discussion on this RFC, and yet a lot of people have
voted -1 on it. This is a little disappointing because I'm not entirely sure
why
people are against it - and no one seems to want to debate it either.
Hey Dan,
The falsy semantics of empty() means that inlining its behaviour to exactly
match
isset() isn't logical.
The problem isn't so much that the behaviour doesn't match some other
pattern in PHP; the problem is that the function doesn't do what its
name says it does.
if any
Hey Derick,
IMO, because it's not obvious whether it is *all* empty, or *atleast
one* empty. The same argument we had before, when we expanded isset() to
be variadic. We had the same discussion then, resulting on keeping
empty() as it is.
One discussion 11 years ago:
On 12 March 2015 at 09:58, Thomas Punt tp...@hotmail.co.uk wrote:
Hey PHP Internals,
I'm not entirely sure why
people are against it - and no one seems to want to debate it either.
I think these were covered in the discussion phase, but I will
reiterate the reasons I voted against it for
Hello PHP Internals!
I'd like to put the variadic empty() RFC to vote.
RFC: https://wiki.php.net/rfc/variadic_empty
Voting will finish in 14 days time on March 21st.
Thanks,
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
13 matches
Mail list logo
