Everything

php

[VOTE] Make empty() a Variadic

php.internals

Thomas Punt

11 years ago

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

Thomas Punt

11 years ago

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 were raised:
1. This will promote the creation of poor code.
2. The proposed semantics of empty() is wrong. It should be equivalent to logically
AND'ing empty()'s arguments together - just like with isset().

To readdress these two points:

1.
Any feature that reduces the amount of written code can be said to make it
easier to write code - regardless of whether this is good or bad code. That
part is up to the developer.

Perhaps the examples in my RFC do not portray this feature in the best of
lights - they were simply meant to show the more extreme usages of empty()
in popular, real-world codebases. So let me provide some statistics.

I ran the following egrep on a number of CMSs (the regular expression used isn't
perfect, but it still gives some sort of approximation):

egrep -rio '(empty\(.*\) *(\|\| *empty\(.*\))+)|(!empty\(.*\) *(&& *!empty\(.*\))+)' project_dir/ | wc -l

Results:
WordPress: 50
OpenCart: 22
phpbb: 36
Drupal: 74
SMF2.1: 266
Joomla: 23

So the proposed short-hand notation of empty() in this RFC does have its
usages. Just as a full disclaimer though, framework codebases will not see
this same usefulness since they don't handle business-specific validation logic
on input fields, web service data, etc (which seems like the predominant usage
of multiple empty()'s in a single condition).


2.
The falsy semantics of empty() means that inlining its behaviour to exactly match
isset() isn't logical.

For example, we can roughly assert that `empty() = ! isset()`. This holds true
with the current semantics proposed by this RFC:

$defined = 1;
// $undefined;
var_dump(empty($defined, $undefined) === ! isset($defined, $undefined)); // bool(true)

If empty()'s arguments were logically AND'ed together, then the above assertion would
not hold true.


So those are the two arguments I'm aware of - if anyone in the -1 camp has any
other reasons, then please do raise them!

Thanks,
Tom

> 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

Dan Ackroyd

11 years ago

On 12 March 2015 at 09:58, Thomas Punt <tpunt@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 clarity.

> 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 arguments passed into empty() are considered falsy, then true
will be returned"

i.e. it doesn't check whether the arguments are 'empty', it's checking
whether they are 'all set and not falsy'. Having a function do
something different to what it's name suggests will lead to it being
used incorrectly a lot of the time.

The other reason I voted no, is that I just don't think this adds
enough to the language to be implemented in core. For at least two of
the examples in the RFC the desired functionality could be implemented
in userland.

The size of the PHP core codebase is already unwieldy. I think any
suggested addition needs to have a clear advantage over being
implemented in userland

cheers
Dan

Thomas Punt

11 years ago

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 arguments passed into empty() are considered falsy, then true
> will be returned"
>
> i.e. it doesn't check whether the arguments are 'empty', it's checking
> whether they are 'all set and not falsy'. Having a function do
> something different to what it's name suggests will lead to it being
> used incorrectly a lot of the time.

Yes, I think this is probably the discursive area that is causing a divide in vote.
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.

> The other reason I voted no, is that I just don't think this adds
> enough to the language to be implemented in core. For at least two of
> the examples in the RFC the desired functionality could be implemented
> in userland.
>
> The size of the PHP core codebase is already unwieldy. I think any
> suggested addition needs to have a clear advantage over being
> implemented in userland

I could understand this POV if it caused a lot of changes, but the patch is
pretty simple a small. I think the potential benefits brought by this feature
is worth its weight against 10 lines of additional code in the language grammar
file.

> cheers
> Dan

Thanks for reclarifying the issues you have with this RFC.

-Tom

Crypto Compress

11 years ago

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 about two separate methods all_empty() and non[e]_empty()?

Thank you!

Matteo Beccati

11 years ago

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/

Crypto Compress

11 years ago

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 my naming suggestions or the
possibility to check many vars on emptiness?
There are these two groups with contrary expectations. What is the
downside to give both a proper solution?

Thanks!

Matteo Beccati

11 years ago

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 Matteo,
>
> 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 contrary expectations. What is the
> downside to give both a proper solution?

The "proper solution" you suggest adds two more functions and I think we
plenty already. We can't make empty variadic because it's ambiguous?
Fine, I think I can live with it.


Cheers

--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Crypto Compress

11 years ago

>>>> 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 contrary expectations. What is the
>> downside to give both a proper solution?
> The "proper solution" you suggest adds two more functions and I think
> we plenty already.

For current problem area there are exactly zero functions.

> We can't make empty variadic because it's ambiguous? Fine, I think I
> can live with it.

Somewhat masochistic approach considering we can unambiguous get rid of
code bloat.

Derick Rethans

11 years ago

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.

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/?l=php-internals&m=109836951711930

I can't find the discussion prior to that though.

cheers,
Derick

Thomas Punt

11 years ago

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/?l=php-internals&m=109836951711930
>
> I can't find the discussion prior to that though.
>
> cheers,
> Derick

Thanks for the link. I wasn't aware this had come up in the past.

-Tom

Pascal MARTIN

11 years ago

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 would not be
clear (when writing/reading code) whether it would test for "all empty /
and" or "at least one empty / or" -- like you explained in one of your
mails. And it appears this is, at least for us, more of a problem than
writing several empty() in a row.

In any case, thanks for your work!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

Thomas Punt

11 years ago

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 semantics
empty() should have).

Thanks to all who participated in the discussions and voting of this RFC!

-Tom