Re: [PHP-DEV] Allow non-variable arguments to empty()

2012-05-05 Thread Richard Lynch
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()

2012-05-05 Thread Richard Lynch
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()

2012-04-13 Thread Nikita Popov
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()

2012-04-13 Thread Etienne Kneuss
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()

2012-04-13 Thread Pal Konyves
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()

2012-04-13 Thread Etienne Kneuss
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()

2012-04-12 Thread Johannes Schlüter
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-04-10 Thread Jelle Zijlstra
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()

2012-04-10 Thread Xinchen Hui
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()

2012-04-10 Thread Kris Craig
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