Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
Sender: stig.bakken@gmail.com
In-Reply-To: <5602BFB3.7090707@php.net>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
	<55DDA4C9.9040603@gmail.com>
	<3C69BF4B-52E6-4D04-8601-8D23DFCC538E@craigfrancis.co.uk>
	<55DDD60F.5090509@gmail.com>
	<8C74463E-DBA2-4015-8159-0B44D973387F@craigfrancis.co.uk>
	<55DE0907.6040904@gmail.com>
	<1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk>
	<55E5EBBF.6020803@gmail.com>
	<0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk>
	<55E6EC36.6090301@gmail.com>
	<E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
	<9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
	<6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
	<55F07BA4.2000204@gmail.com>
	<E8634CF1-C2B4-4C5A-8DDC-531D9599774B@craigfrancis.co.uk>
	<55F6B911.9080400@gmail.com>
	<96BE7F01-D04B-483B-B1A3-B45CED6DFCDC@craigfrancis.co.uk>
	<55F6F08C.1020506@gmail.com>
	<0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@thesba.com>
	<56009C96.5090504@php.net>
	<56013228.50504@gmail.com>
	<5601E01E.6080606@php.net>
	<56027C79.9020404@gmail.com>
	<5602BFB3.7090707@php.net>
Date: Wed, 23 Sep 2015 18:37:38 +0200
Message-ID: <CABM2syvWMhiH-HE=BH=J7DTACsS_83VNt7K=-mKTkifgg+J=LA@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: stig@stigbakken.com (Stig Bakken)

On Wed, Sep 23, 2015 at 5:05 PM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
> Le 23/09/2015 12:18, Rowan Collins a =C3=A9crit :
>>
>>
>> Clearly, people misunderstand what isset() does, but I think an exists()
>> function which mimics it with a slight difference will only add to that
>> confusion - people will say "oh, if only I had PHP 7.1" rather than
>> looking for array_key_exists, for instance.
>
>
> Yes, isset() name is misleading and exists() implements the behavior most
> people actually expect from isset(). If a side effect is to motivate peop=
le
> to adopt PHP 7, why not ?

What is going to motivate people to adopt PHP 7 is its performance
(and at some point the EOL of 5.x), not whether or not it has an
exists() function ;-)

> If they start replacing calls to
> isset()/array_key_exists() with exists(), that's their choice and it can
> only improve overall readability.

The thing is, it won't really improve overall readability, because the
name exists() is still too vague. It may be obvious to the person who
wrote the code (at least for the first two weeks), then you're really
back into the same vagueness that isset() provides.

I'm still in favor of having a variable_exists('varname') function though.

> My main concern is people using
> isset($foo['bar']) and 'naively' assuming it always returns true when the
> array element exists, because wrong assumptions are always potentially
> problematic. The rest is just a question of completeness and consistency(=
).
> IMO, providing an exists() construct is easy to understand and to remembe=
r,
> quite consistent as the scope is the same as isset(), and the drawbacks a=
re
> minimal (including BC break).
>
> Regarding the confusion it may bring, the documentation can be very clear=
,
> stating that the right tool to check for the existence of an array elemen=
t
> in pre-7.1 versions is array_key_exists(), not isset().
>
>> So the purpose of hasitem() was not to be a variant of isset(), but to
>> be a well-defined function which served a specific need that people
>> have. If there are other needs that people have, there can be other
>> functions to serve them.
>
>
> 1) hasitem cannot be implemented as a function. It needs to be defined in
> the lexer/parser the same way as exists(), or do you mean it would receiv=
e a
> string ? Anyway, if you want to allow 'hasitem($foo['bar'])', it cannot b=
e a
> function like property_exists()/functions_exists().
> 2) it defines 2 names instead of 1,
> 3) the 'hasitem' name is not extremely intuitive,
> 4) it is more complex to implement and I'm not sure I can do it :)
> 5) I don't see the reason to make it artificially more complex and harder=
 to
> remember.

Why would you want to add hasitem()? Writing code that treats arrays,
objects and variables as one thing is a bad practice (unless you
really know what you're doing etc.), and we definitely shouldn't
encourage people by giving them more perfumed band-aid to make smelly
code stink less.

>> Looking at some of your edge-cases:
>>
>>> - array_key_exists() does not handle objects implementing ArrayAccess,
>>
>>
>> Sounds like something which could be fixed in array_key_exists, or
>> easily added to hasitem() without all the other baggage.
>
>
> Possible, yes.

And the right thing to do. Or would you want to have to add special
cases for code depending on whether something was an object and
imlemented ArrayAccess? (There are a lot of cases where ArrayAccess
support is wanting, but that's a different issue.)

> Variable variables provide dynamic names :
>
> $var=3D'var_to_check_'.$i;
> if (exists($$var)) echo "$i: $$var";
>
> IMO, that's not much harder than using variable_exists(<string>).

It is certainly a lot less readable.

 - Stig