Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83330
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20150220170854.308596800F2@frontend2.nyi.internal>
References: <20150220170854.308596800F2@frontend2.nyi.internal>
Date: Fri, 20 Feb 2015 12:39:58 -0500
Message-ID: <CAAyV7nFuk+zuS3nMjf79ou0Rr9Qu20jEcE5=wFYiASV5NnYcQg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: ircmaxell@gmail.com (Anthony Ferrara)

Larry,

> Assume for a moment that:
>
> - we tighten up the default passing rules, such that "32" passed to an in=
t works but "32 footsteps" errors (which I thing most are on board with doi=
ng)
> - we include a strict types mode as proposed, including the logical type =
widening cases
> - Zend Engine gets whatever static analysis tools you feel are appropriat=
e.
>
> In what circumstances would I as a Drupal core developer (a few hundred t=
housand lines of code, need high degree of correctness, 2500 developers), c=
ontrib developer (a few thousand lines of code, medium correctness guarante=
e, 3 developers), or a client consultant (a few hundred lines of custom one=
-off code, 1 developer) want to enable strict mode?

So, in what circumstances? Well, I think there are a few cases we need
to talk about:

In legacy systems (Wordpress, existing versions, etc):

In these cases, strict mode would likely go in only extremely
sensitive corners. So areas dealing with cryptography, random number
generation, session security, etc. And it would go in slowly, as
someone revamps it. Not all at once.

Just like unit testing, scalar types would be refactored in very
slowly, in the critical corners of legacy systems. It's unlikely that
more than 1-2% of the entire system would ever become typed.

In non-legacy systems it will likely come down to developer experience
coupled with benefits of the tooling to the problem.

A few hundred LOC script would likely never enable strict mode, and
would be just fine because of it (you can mentally keep a few hundred
LOC in your head at one time).

The larger the project, the more the contributors, the more the
benefits to using strict mode. That's not to say that large projects
would immediately go full strict. It's just pointing out that the
tradeoffs would need to be weighed by the authors.

The proposals that Andrea and now I have put forward give the choice
to the authors, and give the power to them. If they are not convinced
to go strict, then they won't. And there's nothing wrong with that.
But those who do want to go strict can.

The real key that you should be thinking about is when errors are
detected. The stricter the type system, the earlier the errors can be
detected. In a lot of cases, a strict-mode type system can detect the
vast majority (if not all) of type-related errors at compile time.
That's a big benefit for large projects with many moving parts.

> Using strict typing would out more work on me. How much varies with the p=
art of the application. (Closer to IO, more work.) Having it in the languag=
e means I will run into it sometime, even if not in code I originate. If po=
tential performance is not a factor, then what is my carrot? What day to da=
y benefit would I get from doing so other than pedantry?[1] "You can infer =
things" doesn't make it clear what the day to day impact is for me. Concret=
e examples, please.

It's more work on you when you write a single line of code. It's less
work when you're making a single line change in a 1-million-loc app.
It's less work because the type system can verify that the change
won't cause type errors when running (where even unit tests won't give
you the same level of confidence).

Beyond that, I'd highly recommend reading this article:
http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-=
type-systems

> If it would only matter to the Facebook's of the world, well, they've got=
 HACK already. How would this practically help Drupal, Symfony, Zend Framew=
ork, OwnCloud, Doctrine, phpMyAdmin, etc?

Hack hasn't been out to the public for that long of a time, yet look
at the buzz it's generating. Look at the frameworks that are popping
up with it. Look at the libraries.

I think if anything, the appearance of Hack (and its adoption) show
that people want static typing, at least to some level...

Anthony