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 w
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 it
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 c
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 M
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 against
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 - P
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 a
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:
> http://marc.info
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
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 eit
On 12 March 2015 at 09:58, Thomas Punt 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 clarity.
> The falsy
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 wer
12 matches
Mail list logo
