On Sun, Apr 29, 2012 at 2:22 PM, Jille Timmermans <ji...@quis.cx> wrote:
> On 28-04-12 06:27, Kalle Sommer Nielsen wrote:
>
>> 2012/4/27 Jille Timmermans<ji...@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
