Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60368
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F9DB114.9030408@quis.cx>
References: <4F9AFE3D.8010805@quis.cx>
	<CAJW__o1sahxfG-zQzL73D65aTHTqDaepMSTKw97ZRVgXBVXJjA@mail.gmail.com>
	<4F9DB114.9030408@quis.cx>
Date: Sun, 29 Apr 2012 19:48:37 -0700
Message-ID: <CAKOpQSy79+NqXDTYDBF3p=V_OyLSkXxjF5rb6dZnKcDEYDwSXw@mail.gmail.com>
To: Jille Timmermans <jille@quis.cx>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04428ff4af892d04bedc7d21
Subject: Re: [PHP-DEV] Function boolval()
From: kris.craig@gmail.com (Kris Craig)

--f46d04428ff4af892d04bedc7d21
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Apr 29, 2012 at 2:22 PM, Jille Timmermans <jille@quis.cx> wrote:

> On 28-04-12 06:27, Kalle Sommer Nielsen wrote:
>
>> 2012/4/27 Jille Timmermans<jille@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

--f46d04428ff4af892d04bedc7d21--