On Tue, Apr 10, 2012 at 4:12 PM, Jelle Zijlstra <jelle.zijls...@gmail.com>wrote:
> 2012/4/10 Nikita Popov <nikita....@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
