Re: [PHP-DEV] Allow non-variable arguments to empty()
On Thu, April 12, 2012 6:05 pm, Johannes Schlüter wrote: On Wed, 2012-04-11 at 00:53 +0200, Nikita Popov wrote: Currently the empty() language construct only works on variables. You can write if (empty($array)) but not empty if (empty(getSomeArray()). I've mentioned this thought off-list already but let's discuss it officially: A fear I have is that this makes empty more looking like a function, while not being one. Right now one notices quite quickly that it is something else. Things like $check = $condition ? empty : isset; $check($bar); trigger an even more confusing error (Call to undefined function) I'm not sure whether that's a strong argument, but I guess it's good enough to be noted :-) If one doesn't know isset/empty aren't functions, one doesn't understand their purpose nor how variables are used/scoped. If one doesn't know these things, one should learn. Quickly. Call to undefined function is exactly correct. $a = 5; $b = 3; $foo = 'if'; $foo ($a == $b){ echo Nope.; } While it might be as nifty as runkit to do this, it should not be encouraged. Or even allowed. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Tue, April 10, 2012 5:53 pm, Nikita Popov wrote: 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?! On the line number indicated in the message :-) More seriously, if the guts of PHP can easily detect when you are not really write context versus this, just fix the error message to something more meaningful. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Fri, Apr 13, 2012 at 11:37 AM, Pal Konyves paul.kony...@gmail.com wrote: I don't see the point of empty( function() ). You tipically use empty on values that holds information you want to use later in the program flow (a string, an integer). That means you'd better extract it to a variable because you want to avoid calling twice a function that provides this value. You don't always need the value. Browsing around Google it seems that one of the most common source of the function call in write context error is people trying to do if(empty(trim($xyz)). You don't necessarily need the result of trim($xyz), so it's reasonable not to save it into a temporary variable. Another example for example would be a function like this: public function isValid() { if (...) { $this-addError('xyz'); } if (...) { $this-addError('abc'); } if (...) { $this-addError('foo'); } if (...) { $this-addError('bar'); } return empty($this-getErrors()); } Furthermore you don't necessarily have to throw the return value away. For example I commonly write code like this: if (null === $result = $this-foo()) { throw new Exception(...); } $result-doSomething(); You can do something similar with empty(): if (empty($values = $this-getValues()) { return; } $this-doSomethingWith($values); I know, not everyone likes that kind of coding style, but I think it has it's uses. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
Hi, On Fri, Apr 13, 2012 at 15:00, Nikita Popov nikita@googlemail.com wrote: On Fri, Apr 13, 2012 at 11:37 AM, Pal Konyves paul.kony...@gmail.com wrote: I don't see the point of empty( function() ). You tipically use empty on values that holds information you want to use later in the program flow (a string, an integer). That means you'd better extract it to a variable because you want to avoid calling twice a function that provides this value. You don't always need the value. Browsing around Google it seems that one of the most common source of the function call in write context error is people trying to do if(empty(trim($xyz)). You don't necessarily need the result of trim($xyz), so it's reasonable not to save it into a temporary variable. well, empty(trim()) actually is a good example for when you don't want to use empty(). People typically assume empty checks for the empty string here, and it doesn't. Another example for example would be a function like this: public function isValid() { if (...) { $this-addError('xyz'); } if (...) { $this-addError('abc'); } if (...) { $this-addError('foo'); } if (...) { $this-addError('bar'); } return empty($this-getErrors()); } Furthermore you don't necessarily have to throw the return value away. For example I commonly write code like this: if (null === $result = $this-foo()) { throw new Exception(...); } $result-doSomething(); You can do something similar with empty(): if (empty($values = $this-getValues()) { return; } $this-doSomethingWith($values); I know, not everyone likes that kind of coding style, but I think it has it's uses. I believe the change is good, but only because it removes an annoying error condition that is hard to figure out for beginners. Other than that I don't believe it is useful though: people that know what empty() really does can use !expr when expr is not a variable, which is less confusing, especially for strings. Best, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
Well, if you want to use empty in the above mentioned situations, you might need the change. I personally don't like using empty(). I use it only on arrays, that's because semantically fits: array is empty. In other situations I prefer comparing against the according return type because it improves code readability. Dynamic typing in PHP one of the reasons of messy code anyways. I'm gonna try to give you alternatives of design for your examples below: Browsing around Google it seems that one of the most common source of the function call in write context error is people trying to do if(empty(trim($xyz)). You don't necessarily need the result of trim($xyz), so it's reasonable not to save it into a temporary variable. if( trim($xyz) === ); // as I talked about semantics and types above Another example for example would be a function like this: public function isValid() { if (...) { $this-addError('xyz'); } if (...) { $this-addError('abc'); } if (...) { $this-addError('foo'); } if (...) { $this-addError('bar'); } return empty($this-getErrors()); return $this-getErrorsCount(); } Furthermore you don't necessarily have to throw the return value away. For example I commonly write code like this: if (null === $result = $this-foo()) { throw new Exception(...); } $result-doSomething(); I used to use this kind of formula, but I realised It neither improves performance nor readability, especially if you want to use $result after the if statement. You can do something similar with empty(): if (empty($values = $this-getValues()) { return; } $this-doSomethingWith($values); I haven't try this but I assume this code is valid by precedence order. I might be wrong, but still my above argument exist. I know, not everyone likes that kind of coding style, but I think it has it's uses. Etienne Kneuss: People typically assume empty checks for the empty string here, and it doesn't. -- why not? Pal
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Fri, Apr 13, 2012 at 16:22, Pal Konyves paul.kony...@gmail.com wrote: Well, if you want to use empty in the above mentioned situations, you might need the change. I personally don't like using empty(). I use it only on arrays, that's because semantically fits: array is empty. In other situations I prefer comparing against the according return type because it improves code readability. Dynamic typing in PHP one of the reasons of messy code anyways. I'm gonna try to give you alternatives of design for your examples below: Browsing around Google it seems that one of the most common source of the function call in write context error is people trying to do if(empty(trim($xyz)). You don't necessarily need the result of trim($xyz), so it's reasonable not to save it into a temporary variable. if( trim($xyz) === ); // as I talked about semantics and types above Another example for example would be a function like this: public function isValid() { if (...) { $this-addError('xyz'); } if (...) { $this-addError('abc'); } if (...) { $this-addError('foo'); } if (...) { $this-addError('bar'); } return empty($this-getErrors()); return $this-getErrorsCount(); } Furthermore you don't necessarily have to throw the return value away. For example I commonly write code like this: if (null === $result = $this-foo()) { throw new Exception(...); } $result-doSomething(); I used to use this kind of formula, but I realised It neither improves performance nor readability, especially if you want to use $result after the if statement. You can do something similar with empty(): if (empty($values = $this-getValues()) { return; } $this-doSomethingWith($values); I haven't try this but I assume this code is valid by precedence order. I might be wrong, but still my above argument exist. I know, not everyone likes that kind of coding style, but I think it has it's uses. Etienne Kneuss: People typically assume empty checks for the empty string here, and it doesn't. -- why not? What I meant is that when people do: $str = trim($foo); if (empty($str)) { } they typically want to check if the string is empty, i.e. contains 0 characters. They usually forget that empty() will also return true on the string 0. Pal -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Wed, 2012-04-11 at 00:53 +0200, Nikita Popov wrote: Currently the empty() language construct only works on variables. You can write if (empty($array)) but not empty if (empty(getSomeArray()). I've mentioned this thought off-list already but let's discuss it officially: A fear I have is that this makes empty more looking like a function, while not being one. Right now one notices quite quickly that it is something else. Things like $check = $condition ? empty : isset; $check($bar); trigger an even more confusing error (Call to undefined function) I'm not sure whether that's a strong argument, but I guess it's good enough to be noted :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
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
Re: [PHP-DEV] Allow non-variable arguments to empty()
Sent from my iPad 在 2012-4-11,6:54,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. +1 for this, but what about is set? They shou be consistent, :) Thanks 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow non-variable arguments to empty()
On Tue, Apr 10, 2012 at 10:12 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Well, technically it's discussion /and/ vote. I know we've been wanting to get out of the habit of push first, ask later, which is precisely what RFC helps us avoid. Personally, I think any commits for a Nobody's pushing anything. We're talking about implementing it in a fork, it's completely different thing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 I must've missed that part. Who was it that said this would be a separate forked project? If so, then yeah obviously it's not up to us one way or another. And if he's just committing changes locally and/or pushing to an unmerged branch, then there's no harm because it's not actually touching the trunk. What I'm saying is that, before such changes are merged into the actual PHP 5.4 branch, the idea needs to be voted on through the RFC process. Besides, it's a better idea to wait anyway because the simple act of drafting the RFC helps the author to clarify exactly what s/he wants to do before jumping into the code. Furthermore, subsequent input from users may change the direction, forcing the author to rewrite code, which wastes time. And if the proposal is rejected, that person would've written all that code for nothing. So either way you look at it, it seems to me at least that drafting the RFC is the logical first step. --Kris