Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60453
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSxoN5rKbhnE-b-UEwCJ7LU4d1uno6OWEnFRXacwXjt6Ug@mail.gmail.com>
References: <CAF+90c_N7fhQG_62pEgw_qm2LTDJf=ie0tN1PQVq4XNpMEYcmQ@mail.gmail.com>
	<CACwt+Jdn7hS8mszbEhhFtthL7hisG-SaXDahzKb9MhY2ZjOWLA@mail.gmail.com>
	<CABBJUpdAmkEzh9uek2McmdOCkVOWNuHo6kUsFYizGXbRVZ20Dw@mail.gmail.com>
	<CAEZPtU4VF7y3AJEYmPND-dGuWMrU2NCsXRTBF2p+czazrR33nQ@mail.gmail.com>
	<CAH-PCH5wtv07jLHE=_HzPAJHb-OivB=FdROcyh7dPJn8Tt1dVw@mail.gmail.com>
	<CAEZPtU7kv9X0K5kExXOg3nQBqLxXzGq5hc5DRq5dVj7cVdJ55w@mail.gmail.com>
	<396c1a02d4e7195f2b89e26ace2276a6.squirrel@www.l-i-e.com>
	<CAKOpQSy=7+oxT5cqZ6iU17Lknexc1GW9B6uFUvO+BMyCG4uDKQ@mail.gmail.com>
	<CAH-PCH44MT5B8-VoOoipdFHB6Fe5UNrbkmTG46WK9og69UYfJw@mail.gmail.com>
	<CAKOpQSxoN5rKbhnE-b-UEwCJ7LU4d1uno6OWEnFRXacwXjt6Ug@mail.gmail.com>
Date: Fri, 4 May 2012 23:24:02 +0200
Message-ID: <CAH-PCH49OSUpAF0ygV1OnW0+WwhxjoD5Fj=2Z3jENRm=wZnY1w@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: Richard Lynch <ceo@l-i-e.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff256821d81f404bf3c8a7e
Subject: Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
From: tyra3l@gmail.com (Ferenc Kovacs)

--e89a8ff256821d81f404bf3c8a7e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>
> Hmm I'd never really thought about that before.  But now that you mention
> it, that does sound like a problem.  Honestly, I can see no value in
> maintaining a different "standard" for what constitutes a set or not-set
> variable depending on the function.  While I understand Pierre's point th=
at
> people have used $var =3D NULL; in the past to unset variables, I don't t=
hink
> we should actually be supporting that.  After all, $var =3D (anything,
> including nothing) is, by definition, "setting" the variable to something
> (or nothing).
>
> I would analogize this to a printed dictionary.  Let's say you look up th=
e
> word, "glarbofatass".  It's not there.  So you take out another dictionar=
y
> and look it up again.  There's an entry for it, but the entry says, "This
> word has no meaning."  In the first dictionary, "glarbofatass" is not set=
.
>  In the second dictionary, "glarbofatass" is set to the state of having n=
o
> meaning.  Nevertheless, it *is* set.
>
> I've never thought of setting something to NULL as being *literally *the
> same thing as unsetting it (though the purpose and end result are mostly
> the same).  If we didn't have an unset() function, I might feel different=
ly
> about this.  But we do, so really I don't see why "=3D NULL" needs to be =
an
> alias for unset().  To be honest, I doubt this would pose any real BC
> breakage, either, unless someone can point me to an instance where somebo=
dy
> uses "=3D NULL" to unset a variable and then checks it with isset() later=
,
> expecting FALSE.
>
> Personally, I would consider "=3D NULL" =3D=3D unset() but only as it per=
tains
> to isset() to be a bug that should be fixed, not a "feature" that should =
be
> preserved.  And if we make that change (perhaps target it for PHP 6 since
> it would nonetheless pose a fundamental logic change, albeit an extremely
> minor and low-impact one), then this RFC suddenly makes a lot more sense
> while allowing the scope to be limited to empty() without creating any
> annoying contradictions.
>
>
then maybe you should open a separate rfc and thread for that.
btw. $foo =3D null; doesn't equals/aliases  unset($foo); only isset() writt=
en
in a way so that it checks the existence of the variable AND if it exists
then checks that it's value isn't null.
maybe this isn't nice for a newcommer to the language, but it is how isset
works for a pretty long time now, and changing it would be a major BC break=
.
not impossible, but that would definitively deserve a separate RFC and
discussion.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--e89a8ff256821d81f404bf3c8a7e--