Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83916
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.180 as permitted sender)
References: <BAY178-W418C61DF38879BED71640EDE140@phx.gbl>	<3d639901ae85227b219e7ee59b3140fe@mail.gmail.com>
 <CA+kxMuQ52SOWp0dP0okVHrb8wF9U5TUX8OcYpNBP4rEPvdrpFA@mail.gmail.com>
In-Reply-To: <CA+kxMuQ52SOWp0dP0okVHrb8wF9U5TUX8OcYpNBP4rEPvdrpFA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQGwbbdURx2shUG2o7Zj2Ywptu8MnAHNhHseASj3TG+dK2AVwA==
Date: Thu, 26 Feb 2015 21:19:58 +0200
Message-ID: <bf4d067c4e0a67964a55336a84df2187@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Theodore Brown <theodorejb@outlook.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] A different user perspective on scalar type declarations
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Dan Ackroyd [mailto:danack@basereality.com]
> Sent: Thursday, February 26, 2015 8:49 PM
> To: Zeev Suraski
> Cc: Theodore Brown; internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarations
>
> On 26 February 2015 at 17:48, Zeev Suraski <zeev@zend.com> wrote:
> >> From: Theodore Brown [mailto:theodorejb@outlook.com] 2. Strict types
> >> are important in some cases.
> >>
> >> I would *want* any value with the wrong type (even a string like
> > "26")
> >> to be flagged as an error when passed to a function expecting an
> > integer.
> >
> >
> > I agree completely;  However, such use cases like this are a lot less
> > common than the situations where you do want sensible coercion to be
> > allowed.
>
>
> That's just not true on medium to large code bases, and if you think
> that's
> true it's possibly an explanation of why you don't see why people want
> strict
> types so much.
>
> In most applications, the part of the code that is exposed to the outside
> world and has to convert strings or unknown types into known types is a
> very
> small layer at the outside edge of the application.
>
> The vast majority of code written for non-trivial applications has no
> contact
> with the outside world. Instead it only communicates to other layers
> inside
> the application where the types required are fully known, and so the
> parameters passed should already be in the correct type. And so type
> coercion is at best unneeded, and usually not wanted.
>
> I can understand why people might only want to use weak types for their
> code base, but for you to continually dismiss people's desire for strict
> types
> after all this has been explained to you multiple times is very
> depressing.

First, I'd like to point out that I'm not talking about 'weak' (dynamic)
typing, but the new coercive typing rules.  The coercive typing rules are a
lot stricter than the dynamic conversion rules that are employed throughout
PHP.

Now, when you mention the outside the world - what are you referring to?  If
you only refer to user input, then I agree.  But if you add data sources -
such as databases, web services, filesystem and others - then I disagree.
Even in large projects, PHP interacts predominantly with such data sources
(as well as user input, of course) - and these all provide data
predominantly as strings.  Pure computations with no feed of outside data
are not nearly as common a use case for PHP (and web apps/services in
general).  Coercive typing is a much better fit not just handling user
data - but also handling all kinds of input data, regardless of where it
comes from.  Strict is useful in narrow cases - mainly math-intensive
computations of different sorts.  That's a valid but not nearly as common a
use case for PHP.  Given that a 2nd mode comes at a price (complexity,
people assuming it is what it's not,  further technological division) - it's
just not worth it.  We need to aim for the one mode that caters to the 90+%,
and not try to be everything to everyone at the cost of much increased
complexity, not when they can very easily implement it in very simplistic
and easily optimizable custom code.

Zeev