Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:80573 php.internals:80577
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me>
	<CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com>
	<4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me>
	<9a033dd1f223f854e760924d118ab812@mail.gmail.com>
	<CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com>
	<2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com>
	<F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me>
	<6105ea99002e634373c09685310e26a6@mail.gmail.com>
	<D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me>
Date: Thu, 15 Jan 2015 10:55:22 -0600
Message-ID: <CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Zeev Suraski <zeev@zend.com>, Richard Quadling <RQuadling@gmail.com>, Leigh <leight@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=90e6ba3fcd29cc76d7050cb3b82d
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: pencap@gmail.com (Mike Willbanks)

--90e6ba3fcd29cc76d7050cb3b82d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Andrea,

On Thu, Jan 15, 2015 at 8:09 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Zeev,
>
> > On 15 Jan 2015, at 11:56, Zeev Suraski <zeev@zend.com> wrote:
> >
> > Andrea,
> >
> > I'm not sure what you're basing that assumption on.  The incidental
> > interactions you (or anybody) may have with 'the community', by no way
> > represent the opinion of the community at large.  The vast majority of
> the
> > PHP community never ever interacts with internals@, never attend
> > conferences, don't write blog posts about PHP and are generally
> completely
> > 'under the radar'.  I would actually go to argue that the people who do
> > attend conferences, participate on internals@ or write blog posts - are
> not
> > representative of the PHP userbase at large.  The vast majority of
> > developers I bump into - you will never ever hear from.  They constitut=
e
> the
> > vast majority of the ~5M strong PHP developer base.
> >
> > So even though my belief / educated guess is that the vast majority of
> the
> > PHP userbase would prefer to see strict typing kept off this language,
> I'm
> > not going to argue that - but we must not argue the opposite either,
> based
> > on the non-representative anecdotal data from a few dozen people.
>
> Whether or not they are in the majority, a very large portion of PHP
> developers would prefer strict typing. In particular, the most vocal ones
> would seem to. There are also a lot of PHP developers who would prefer we=
ak
> typing. Thus we have a problem: either approach to scalar hints will upse=
t
> a large portion of the community.
>

I actually quite disagree with that statement.  Both as a library/framework
developer and a user land developer I find strict typing to be more of an
issue.  For instance:

function foo(int $foo)
foo('23');

This would be a pain and cause constant glue from userland:
Option A: Force Cast aka (int) '23'
Option B: Check for digits via ctype_digits then force cast
etc.

To provide more of a point here, variables coming from HTTP are always a
string, this makes strict casting a troubling item, considering that the
main way of fetching input is coming from the web specifically.  I'm
certain this would also affect other areas as well such as reading csv
files and more.  To me this point alone makes a vastly strong statement
against strict typing and as such, it would make life far more difficult
for library developers and user land developers alike.


>
> >
> >> Myself, I might have been somewhat happy with just weak hints, but
> >> it would upset an awful lot of developers who would like some measure =
of
> >> strict typing. Developers who would most likely not use the new scalar
> >> type
> >> hints, because they weren=E2=80=99t strict. And if nobody uses them, w=
hy add
> them?
> >
> > How do you deduce that 'nobody uses them' from the fact that some group
> of
> > people said they won't?  I'm sorry, but it makes no sense, especially
> given
> > the positive feedback you saw on internals, making it clear that there
> would
> > be in fact people using it.
>
> Not all of it was positive. Sure, a lot of people would use them though,
> but I=E2=80=99ve heard quite a few developers say they wouldn=E2=80=99t u=
se them and
> continue to use manual (!is_int($foo))-style assertions.
>
> > If there's one thing that's worse than introducing an alien concept lik=
e
> > strict typing into PHP, it's introducing it as a feature that will
> include
> > all the negatives of this alien concept, PLUS have the ability to
> radically
> > change how it behaves based on a runtime option.
>
> This isn=E2=80=99t a runtime option, it is entirely compile-time. Much li=
ke
> namespaces are not a runtime option. There isn=E2=80=99t even the ability=
 to toggle
> it at runtime, unless we somehow add some ability to edit the flags on
> individual opcodes.
>

I agree with the others in that declarative syntax to change it is a bad
idea.  It actually reminds me of ECMAScript 5's "use strict" (
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mo=
de)
condition.   Changing the definition based on user land scripts can lead to
bugs and inconsistencies in a library developers purpose of a package and
cause bad conditions.  It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict).  So I
don't really understand where the gains of this would come from and it
actually causes me concern in that what if a developer forgets to define
strict and you're entire system is built on strict.

Regards,

Mike

--90e6ba3fcd29cc76d7050cb3b82d--