Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59684
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: <CAFp3-p90hjjvj90jt86UsEv=VT19vOvdDN2YoGS1+cOAF-NDZg@mail.gmail.com>
References: <CAF+90c_hj7PrWbm42dj0DhN7Ygmc=vckP=bcYfsVuod4=RrOQQ@mail.gmail.com>
	<CAFp3-p90hjjvj90jt86UsEv=VT19vOvdDN2YoGS1+cOAF-NDZg@mail.gmail.com>
Date: Tue, 10 Apr 2012 16:15:18 -0700
Message-ID: <CAKOpQSwODuPci5J9-EMWsTfGF31Q5YzBPibkjrc33yrS36=syQ@mail.gmail.com>
To: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04447f47d9168904bd5b4ba4
Subject: Re: [PHP-DEV] Allow non-variable arguments to empty()
From: kris.craig@gmail.com (Kris Craig)

--f46d04447f47d9168904bd5b4ba4
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 4:12 PM, Jelle Zijlstra <jelle.zijlstra@gmail.com>wrote:

> 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
> >
> >
>

+1 on this.  Could you draft this into an RFC for us?

--Kris

--f46d04447f47d9168904bd5b4ba4--