Function boolval()

$bools = array_map(function($a){ return((boolean) $a); }, range('a', 'z'));
$bools = array_map('boolval', range('a', 'z'));

Second one seems more readable to me...

Sorry, I forget to hit reply-all sometimes... So lets try that again...

Why is this going to be more beneficial to implement? Is it that you
feel readability of the closure is too difficult or that you feel
there is a use case that presents further benefits for implementing a
boolval function, beyond that of just readability or other subjective
preferences?

Personally, I would feel something like array_filter(range('a','z'));
is way more readable than all of the above and makes a lot more sense
to me.

Under most circumstances, one does not tend to care about the truth in
expression unless it is truth. So the following code is far more
practical than the suggestions being made here:

if (!array_filter(array(0,false,null,'', array()))) {
/* The array is made up entirely of falsey values /
} else {
/ The array is not made up entirely of falsey values */
}

I'm not saying the function is useless. I'm just saying PHP already
offers more than 1,000 functions through core, alone, and adding just
one more function that doesn't seem to offer anything new really isn't
sounding like a promising idea to me. We only add to people's
confusion more by offering them dozens of choices to accomplish the
same thing. We've all heard the arguments of "print vs. echo", or X vs
Y. There's no practical reason to include this in core being presented
hear apart from "I like it more..."

2012/4/27 Jille Timmermansjille@quis.cx:

I suggest we add a function boolval(). It simply converts the given

argument
to a boolean, like strval(), intval() and floatval(). I already have an
implementation ready[1].

Why?

• It is missing in the current list of *val()-functions and people
  expect it
  to exist. I'd say it is an inconsistency.
• It can be used as a callback, which is why a bool-cast does not
  suffice.

Does it really matter nowadays when we got closures anyway:

$bools = array_map(range('a', 'z'), function($a){ return((boolean) $a);
});

Closures can achieve the same goal but are less readable as Sebastian
Krebs already pointed out and still confuses the programmer.

Sherif Ramadan wrote:

Why is this going to be more beneficial to implement? Is it that you
feel readability of the closure is too difficult or that you feel
there is a use case that presents further benefits for implementing a
boolval function, beyond that of just readability or other subjective
preferences?

Personally, I would feel something like array_filter(range('a','z'));
is way more readable than all of the above and makes a lot more sense
to me.

That's just an example of course. (And doesn't even do the same thing)

Under most circumstances, one does not tend to care about the truth in
expression unless it is truth. So the following code is far more
practical than the suggestions being made here:

if (!array_filter(array(0,false,*null,'', array()))) {
/ The array is made up entirely of falsey values /
} else {
/ The array is not made up entirely of falsey values */
}

I'm not saying the function is useless. I'm just saying PHP already
offers more than 1,000 functions through core, alone, and adding just
one more function that doesn't seem to offer anything new really isn't
sounding like a promising idea to me. We only add to people's
confusion more by offering them dozens of choices to accomplish the
same thing. We've all heard the arguments of "print vs. echo", or X vs
Y. There's no practical reason to include this in core being presented
hear apart from "I like it more..."

I do agree it isn't perfect to have both casts and conversion functions
but we're too late now anyway. They both exist - but the boolval conversion
function is missing, which is - I think - even worse than "yet another
function".

-- Jille

+1

Please correct me if I'm mistaken, but if PHP only included functions for
stuff that could not be done through some other means, we'd probably have
just a small fraction of the functions we have now. Why must PHP suddenly
start following such a rigid policy, and why now? Personally, I like the
fact that there are multiple ways of doing things. I like the fact that
PHP contains functions that are more or less abstractions meant to make my
life as a developer that much easier. One of PHP's best selling points
IMHO is its flexibility; that there's a function for just about everything
lol.

If we already have intval(), strval(), and floatval(), why must we draw a
line in the sand and say that boolval() would be "one too many"?! If we
want to have a conversation about re-thinking the use-cases for PHP
functions, that's fine, but I honestly don't think that turning this RFC
into a referendum on that is the best approach. If boolval() will further
the KISS principle (think 2 parentheses instead of 8 lol), then personally
I don't see what the big deal is.

--Kris