Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <55FC988E.5000502@php.net>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com> <55FB3A60.1040601@gmail.com> <55FB4270.7000204@lsces.co.uk> <55FB4969.7080600@gmail.com> <55FB5BA6.6050606@lsces.co.uk> <55FBF265.5000502@gmail.com> <55FBF7B7.4050603@lsces.co.uk> <55FC1A77.7090406@gmail.com> <55FC221A.7020108@lsces.co.uk> <55FC2588.6030809@gmail.com> <55FC2B17.3070909@lsces.co.uk> <55FC2F2F.9060403@gmail.com> <55FC33F1.3090903@lsces.co.uk> <55FC354B.5070209@gmail.com> <55FC39B2.5070005@lsces.co.uk> <55FC45C7.9010202@gmail.com> <55FC4991.1050903@lsces.co.uk> <7872E9F4-AE19-4681-B2EF-215751AE4CBE@thesba.com> <op.x4573wqthuszwh@tsukapiou.home> <55FC5A14.8020301@gmail.com> <op.x46bf5grhuszwh@tsukapiou.home> <BAAC6F1B-3DDC-4D0C-8802-3B8210AEF13E@gmail.com> <55FC988E.5000502@php.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sat, 19 Sep 2015 13:25:31 +0100
To: =?ISO-8859-1?Q?Fran=E7ois_Laupretre?= <francois@php.net>,Benoit Schildknecht <bensor987@neuf.fr>,internals@lists.php.net
CC: Robert Williams <rewilliams@thesba.com>
Message-ID: <4069D3FD-41BA-465B-89BE-670B677FA783@gmail.com>
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

On 19 September 2015 00:04:46 BST, "François Laupretre" <francois@php.net> wrote:
>So, as everyone seems to have exposed his arguments, I think we need an
>RFC and a patch now. Unless anyone volunteers, I'll write the patch.
>Who 
>can write the RFC ? Robert ?

I may have given the impression of stubbornness in this discussion, but I have listened to people's arguments, and am considering an RFC proposing two functions:

- a syntactic sugar for array_key_exists and property_exists, maybe called hasitem(); hasitem($foo['bar']) would check $foo has the item 'bar', but hasitem($foo) would be an error

- a function for checking if a variable is in the current symbol table, maybe called variable_exists to match class_exists etc; it would take a string naming the variable, e.g. variable_exists('foo'); I am worried that this will be abused, and tempted to give it a "scarier" name

Importantly, neither of these should be presented as "fixing isset", since I have seen absolutely zero evidence that it is broken; the names and behaviours are designed to highlight that these are functions to be used for specific purposes.

Regards,
-- 
Rowan Collins
[IMSoP]