Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88787
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <AA.80.41961.18A8D165@pb1.pair.com>
References: <5C.21.16518.AA80C165@pb1.pair.com> <CAKxcST80gxyXzfwtwhUzkmmY1c1QMmmt_u0u4g-2yqxvTCDz-Q@mail.gmail.com>
 <AB.35.04042.5F70D165@pb1.pair.com> <CADajX4AAHP86MSB8UFpRUjuCUWxxEUtYTSqwvWjLqD44itab5Q@mail.gmail.com>
 <AA.80.41961.18A8D165@pb1.pair.com>
Date: Wed, 14 Oct 2015 09:43:58 +0100
Message-ID: <CAPg3XxLm=fZass_SyMfcRHcyS2LOuwGhqoJg-bAPseqQkhadJQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0445182f931bfd05220c9245
Subject: Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson
From: petercowburn@gmail.com (Peter Cowburn)

--f46d0445182f931bfd05220c9245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 13 October 2015 at 23:49, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Adam,
>
> Adam Harvey wrote:
>
>> (Sorry Andrea, I'm picking on your e-mail because it's easiest, but
>> it's a general response to the thread.)
>>
>
> Ah, don't worry about it.
>
> I agree that we should do something, but I think we should alias.
>>
>> We allow both "int" and "integer" in settype() and we allow it in type
>> casting =E2=80=94 the two other places where a user can specify a type f=
or
>> conversion.
>>
>
> We also support 'real' and 'binary' in casts, but these are quite rare,
> and I think (int) is a lot more common than (integer), heck, the manual
> uses it.
>
> I still think it's a poor choice to not allow both in type
>> declarations: while I'm generally a fan of having one way to do
>> things, I believe that the inconsistency in the language is worse than
>> the potential ambiguity in style guides.
>>
>
> Well, we could support the full set of names (int, integer, long, float,
> double, real, string, binary, bool, boolean) everywhere, but this is a bi=
t
> unruly. It's better to pick one and stick to it, and discourage the us of
> the others or slowly phase them out.


I'm going to keep beating this drum, but I disagree with that last
statement.  We *should* at the very least support both full and short names
for "int" and "bool": again, why stomp on people's muscle memory over
something so utterly trivial to support?  The only argument that I've
gleaned from this thread is "but, but, it's *inconsistent*" and that is not
something I disagree with at all. I simply prefer to support them, clearly
most others here don't.

An arbitrary code search shows that, for people currently documenting their
arguments with phpdoc, a non-trivial number of people choose the longer
terms for bool/int. [1] [2]



> Hell, _I_ still can't remember which out of "int" and "integer" is the
>> right one, and I've now written a decent amount of PHP 7 code _and_
>> wrote half of the documentation for this.
>>
>
This. So much this. Just like you, I keep typing "integer", and "boolean".
Maybe us folks on the documentation team have some mental deficiency that
the more internals folks don't have? (I'm only half-joking there.)


>
> The rule seems to be 'integer' in English, 'int' in code, for the most
> part.


I'd agree with "for the most part" but I disagree with that part being a
large enough part to ignore the other parts.


>
> Plus, if we error when "integer" is used, we've moved people's cheese
>> anyway (by disallowing the class name). Let's not compound that by
>> forcing them to do busywork.
>>
>
> I think this would drill into you that it's 'int' not 'integer' pretty
> quickly, so it wouldn't become annoying.


It's int. It's int. It's int. It's int.  For this to be resolved, at least
for me, personally, there's going to need to be a lot more drilling. I like
to think that I'm not alone in this respect, but maybe that's not the case.


>
>
>> Adam, who hopes that anecdote doesn't say more about his working
>> memory than the design of the language.
>>
>>
Peter, who is a little tired of the folks beating the "more errors please"
drum.


>
> PHP is a confusing behemoth, don't worry, you're not alone :)
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[1] "@param boolean"
https://github.com/search?l=3Dphp&q=3D%22%40param+boolean%22&ref=3Dsearchre=
sults&type=3DCode&utf8=3D%E2%9C%93
[2] "@param integer"
https://github.com/search?l=3Dphp&q=3D%22%40param+integer%22&ref=3Dsearchre=
sults&type=3DCode&utf8=3D%E2%9C%93

--f46d0445182f931bfd05220c9245--