Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83073
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPhkiZxvJda-Q1WEr7LTrX9BCHKs0QapQ8f=hh8L+1SNC+KFHQ@mail.gmail.com>
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
	<CAF+90c_S3xT07F-4smHeD=BTuSG9VQZxZ==mhyOzDuBw5QPX_Q@mail.gmail.com>
	<54E3E27B.2010903@lerdorf.com>
	<CAF+90c8o8GtO9=7JJ3Jmjzg-=qVAD1aiQaU32joOeD6XH_f4hg@mail.gmail.com>
	<2f99c47df51fa6c73131032ec50fade0@mail.gmail.com>
	<CAPhkiZxvJda-Q1WEr7LTrX9BCHKs0QapQ8f=hh8L+1SNC+KFHQ@mail.gmail.com>
Date: Wed, 18 Feb 2015 14:49:56 +0000
Message-ID: <CALwr1G=wEYNLegXrNerPk0Yp2AW5cPhdkzWUaD4ik_RrCPw6Gg@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Zeev Suraski <zeev@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	Rasmus Lerdorf <rasmus@lerdorf.com>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

Hi all,

On 18 February 2015 at 09:14, Andrey Andreev <narf@devilix.net> wrote:
> Hi,
>
> On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski <zeev@zend.com> wrote:
>> I am wondering what the point is indeed with preventing "123" to 123.  S=
o
>> far, all the concrete use cases people brought up had to do with "Apple"=
 or
>> "100 dogs", but nobody ever seems to be able to explain why converting "=
123"
>> to 123 is likely to be a problem real world.  Is it really just static
>> analyzers?
>>
>
> I too am curious about the potential issue with "123" to 123
> specifically, although it could be seen as a subset of another problem
> that is solved with strict hints - numeric-character string
> identifiers being erroneously treated as integers.

If I may interject briefly (doing it anyway!), there are so many
concepts being munged together that there's bound to be confusion (on
the part of idle readers like me). For this specific case, would I as
someone who wants strict/strong typing really care whether =E2=80=9C123=E2=
=80=9D was
coerced to an integer? No. Others are free to disagree. I actually
don=E2=80=99t mind there being a certain amount of logical coercion between
types where it makes sense. That=E2=80=99s not, per se, fully in accordance
with strictest to the strict degree typing which was Nikita=E2=80=99s point=
.
Coercion is itself a symptom of weak typing, so the more coercion one
introduces, the weaker the typing.

However, =E2=80=9C123=E2=80=9D is exceptional. It=E2=80=99s redefining an i=
nteger as =E2=80=9C an
integer or a string comprised wholly of digits without leading zeroes,
with an optional leading hyphen, and representing an integer up to
PHP_INT_MAX=E2=80=9D, i.e. an integer or a string with a real number that b=
e
made an integer without loss. No other string need apply. That=E2=80=99s no=
t
strict-strict typing (there=E2=80=99s coercion) but it=E2=80=99s probably s=
trict
enough to pass muster (it=E2=80=99s one single obvious coercion under limit=
ed
circumstances).

Then again, it=E2=80=99s an exception that requires a long sentence. It=E2=
=80=99s just
not clear, to me, if this is the sole intended exception, or if that
sentence needs to be expanded to a paragraph. A section? Are we going
to need a chapter? I=E2=80=99m assuming octals-in-a-string are a no-go to b=
e
coerced whereas others might just see an integer with superfluous
leading zeroes.

In a future RFC revision, it might be nice to have a table of the
specific coercion rules applicable to a weak/strong/single-unified
option. Granted, final implementation details may be not 100% certain,
but in this case any variation in implementation can have significance
as to whether something is weak/strict/or lies somewhere else on the
spectrum in between.

So, I agree with Nikita that this is less than strict typing, but one
single logical exception doesn=E2=80=99t instantly demote it to extreme wea=
k
typing if its sufficiently narrow in scope. We are compromising, no?

It=E2=80=99s imperfect in other ways, but I=E2=80=99ll let others debate if=
 those are
significant or not.

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com