Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82066
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)
MIME-Version: 1.0
In-Reply-To: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
Date: Fri, 6 Feb 2015 21:22:44 +0100
Message-ID: <CAF+90c-s=s5P-w-P48iqm9J+RJn1DvKTnDCsn2sYDxHmmg=7NA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043894f9ee61e2050e712e46
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d043894f9ee61e2050e712e46
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Good evening,
>
> At long last, I=E2=80=99m going to put the RFC to a vote. It=E2=80=99s be=
en long enough -
> I don=E2=80=99t think there needs to be, or will be, much further discuss=
ion.
>
> I=E2=80=99d like to make sure that everyone voting understands the RFC fu=
lly.
> Please read the RFC in full: the details are important. And if  anyone ha=
s
> any questions or uncertainties, please ask them before voting. I am very
> happy to answer them.
>
> I would urge everyone who wants type hints to vote for this RFC. It is no=
t
> a perfect solution, but there can be no perfect solution to this issue.
> However, I think it is better than most of the alternatives suggested thu=
s
> far - see the rationale section, and previous discussions. Crucially, thi=
s
> RFC would keep PHP a weakly-typed language, and not force either strict
> typing, nor weak typing, on anyone who does not want it. It would allow t=
he
> addition of type hints to existing codebases. It would not create a
> situation where userland functions are strict yet internal functions are
> not, because the strict mode affects both. I=E2=80=99ve tested the implem=
entation
> myself on my own code, and it worked well, providing benefits other
> proposals would not have given (see my previous post about my experiences=
).
>
> Voting starts today (2015-02-05) and ends in two weeks=E2=80=99 time (201=
5-02-19).
> In addition to the vote on the main RFC, there is also a vote on the type
> aliases issue, and a vote to reserve the type names for future RFCs=E2=80=
=99 sake
> if this RFC fails.
>
> The RFC can be found here, and it contains a voting widget:
> https://wiki.php.net/rfc/scalar_type_hints
>
> Thank you for your time.
>

After much initial reluctance, I've voted in favor of this RFC.

I'm a proponent of strict scalar typing. I will not explain the reasons
behind this here, because they have been covered extensively in the
previous threads and I no longer have the patience for such heavily
prejudiced discussions. As such this mail is really an explanation why I am
voting for an RFC defaulting to weak types, despite my misgivings with such
a typing scheme.

A primary appeal of this RFC is that the "strict_types" mode not only
influences userland function calls, but also calls to internal functions. I
really appreciate the symmetry behind this - a plain strict scalar typing
proposal would only cover userland calls, while this also enforces proper
type usage with internal ones. This seems very reasonable, as the same
arguments in favor of strict scalar types for userland functions apply
nearly identically to internal functions as well.

Another advantage of this approach is that there are fewer interoperability
issues between libraries using strict typing internally and external code
not making use of it. A pure strict scalar typing proposal would likely
cause severe integration issues between code using scalar types and code
not using them at all and as such using relatively unpredictable data
types. This issue will not be entirely alleviated by this proposal
(primarily due to the lack of generic or semi-generic types), but it will
be much more limited and libraries should be able to safely use the strict
typing mode without alienating users.

Lastly, I would like to talk about cognitive overhead. This RFC uses a
per-file typing mode declaration and there may be concerns about having to
mentally adjust to different modes being used in different files of a
project. While I think this is an important concern, there are two
ameliorating factors:
a) It is very likely that libraries using strict scalar types will use them
in the entire project rather than having a mix of different modes in
different files. Similarly applications will likely also either be fully
strictly typed or have clearly separated front- and backend components
where only the latter uses strict scalar types.
b) Within one file, this RFC actually removes mental overhead, because type
declarations will behave identically for userland and internal functions.
You won't have to deal with some functions being liberal and some being
strict.

Thanks,
Nikita

--f46d043894f9ee61e2050e712e46--