Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_hj7PrWbm42dj0DhN7Ygmc=vckP=bcYfsVuod4=RrOQQ@mail.gmail.com>
References: <CAF+90c_hj7PrWbm42dj0DhN7Ygmc=vckP=bcYfsVuod4=RrOQQ@mail.gmail.com>
Date: Tue, 10 Apr 2012 19:12:59 -0400
Message-ID: <CAFp3-p90hjjvj90jt86UsEv=VT19vOvdDN2YoGS1+cOAF-NDZg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0444814784c12204bd5b4311
Subject: Re: [PHP-DEV] Allow non-variable arguments to empty()
From: jelle.zijlstra@gmail.com (Jelle Zijlstra)

--f46d0444814784c12204bd5b4311
Content-Type: text/plain; charset=ISO-8859-1

2012/4/10 Nikita Popov <nikita.ppv@googlemail.com>

> Hey internals!
>
> Currently the empty() language construct only works on variables. You
> can write if (empty($array)) but not empty if (empty(getSomeArray()).
>
> The original reason for this restriction probably is that - in a way -
> it "doesn't make sense" to pass anything but a variable to empty() as
> you could just use the ! operator in this case. if
> (empty(getSomeArray())) is logically equivalent to if
> (!getSomeArray()).
>
> I'd like to propose to change empty() to accept arbitrary expressions.
>
> The reason is simple: Even though it is possible to write if
> (!getSomeArray()) with the same effect, if (empty(getSomeArray()))
> reads much nicer. !getSomeArray() to me somehow implies that
> getSomeArray() may return a bool(false) or something like that. On the
> other hand empty(getSomeArray()) seems naturally fit for checking for
> empty arrays.
>
> Another reason is that currently you get a very obscure error message
> if you try to use empty() on a function return value: "Can't use
> function return value in write context". Aha. Where did I try to write
> to the return value?!
>
> So, what do you think?
>
>
I think this is a useful simplification of the language, removing an
unnecessary exception. Would it also make sense to make empty() into a
library function instead of a language construct? That would not result in
any BC break as far as I can see, but would allow some things that are
currently impossible (e.g., a method called "empty") and further simplify
the language.


> Nikita
>
> PS: The patch is trivial: https://gist.github.com/2355274
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d0444814784c12204bd5b4311--