Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.34 cause and error)
Message-ID: <54E831BA.80609@fischer.name>
Date: Sat, 21 Feb 2015 08:20:26 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <DUB113-W13349F3B070957C64B0AF18F92B0@phx.gbl>
In-Reply-To: <DUB113-W13349F3B070957C64B0AF18F92B0@phx.gbl>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  On 21.02.15 06:11, Thomas Punt wrote: > Hello Internals! >
    The following RFC aims to make empty() have a variable arity: https://wiki.php.net/rfc/variadic_empty.
    This is a simple feature that enables for a short-hand notation of checking
    multiple expressions for emptiness (which is a pretty common thing to do).
    > I have avoided including the is_*() functions into this RFC because my
   main priority is to get this particular feature into PHP 7.0 before feature
    freeze. Provided I have some free time over the next week, I'll write up
   another RFC + patch to cover the is_*() functions. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Subject: Re: [PHP-DEV] [RFC] Make empty() a Variadic
From: markus@fischer.name (Markus Fischer)

On 21.02.15 06:11, Thomas Punt wrote:
> Hello Internals!
> The following RFC aims to make empty() have a variable arity: https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables for a short-hand notation of checking multiple expressions for emptiness (which is a pretty common thing to do).
> I have avoided including the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions.


From the RFC:
> This behaviour seems to be the most prevalent usage of multiple empty
checks in a condition, therefore benefitting the most end users.

Here I disagree.

I would have assumed from the start that empty() would only return true
if *all* of the entries are empty, i.e. AND things together.

If we enable variable arity then it will join the group of function
where no user sanely can remember if in_array/etc. take the
needle/haystack first or second argument. I.e. whether it will OR or AND
all arguments.


From the RFC:
> Also, it will make empty() more inline with the not-too-disimillar
isset(), which is good for the Principle of Least Astonishment (mainly
aimed at neophyte developers).

  From http://php.net/manual/en/function.isset.php :
  "If multiple parameters are supplied then isset() will return TRUE
  only if all of the parameters are set. Evaluation goes from left to
  right and stops as soon as an unset variable is encountered."

But this is an AND: "... if all ... are set":

"isset($a,$b)" behaves like "isset($a) && isset($b)"

IMHO this absolutely violates your POLA because as I said this is also
how I would assume empty() with variable arguments would work: Only
return true if all are true.


My personal opinion is that any attempt to change this is ill-fated
because people will no be able to memoize the exact usage of it because
it would mean different things to different people and would just add
more confusion.

-1 on the proposed change.


- Markus