Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.174 as permitted sender)
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
 <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com>
 <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com>
 <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com>
 <53C563B3.6060905@gmail.com> <CAPhkiZwvqW=d3Ayn-=Hx5HfkcOFB+gQ6rRoFThxA8hESK4WLrA@mail.gmail.com>
 <54536191-1B92-4933-973F-0C8289D13A4C@ajf.me> <00d12255efc53466245b21a83ff7d474@mail.gmail.com>
 <1CE2ACC0-D6CA-407B-99C7-4914311B733E@ajf.me> <53C6CFB7.8090908@sugarcrm.com>
 <118BB3D7-BE52-44AB-BD0E-942830D44A2A@ajf.me> <f5916534f96ebe14b4d7c7f6ef66dc4e@mail.gmail.com>
 <9B7B8559-61FE-493D-BAEE-53E8C84D5E91@ajf.me> <221d3e5c1be1ee2277e05027912762db@mail.gmail.com>
 <AD0479EE-1FC7-4139-B535-514D123E76FE@ajf.me>
In-Reply-To: <AD0479EE-1FC7-4139-B535-514D123E76FE@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwLGIEDMAn0sGnoDLh5SUQGHGGlvAc6JkJwCOz0MXAIckqSUAcstGVQBlZLKHwF5/8irAjNOBKMBp385lgLwVEHDAe12+6oCvuX74AIdDvTgAg5W4NmZQPSS0A==
Date: Thu, 17 Jul 2014 00:42:19 +0300
Message-ID: <0476c27fc2a44f715ed50052e47a3b1a@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Andrey Andreev <narf@devilix.net>, 
	Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Thursday, July 17, 2014 12:17 AM
> To: Zeev Suraski
> Cc: Stas Malyshev; Andrey Andreev; Rowan Collins;
internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
>
> On 16 Jul 2014, at 22:10, Zeev Suraski <zeev@zend.com> wrote:
>
> > Stricter typing does not belong in PHP.  If it did, we'd have it in
> > internal functions, implicit casting and the rest of the language in
> > general.  We don't.
>
> This proposal isn't that much stricter than zpp, aside from booleans I
suppose.
> It's not like we allow literally anything as function arguments for
internal
> functions.

We do, mostly.  We accept "42 ", " 42" and "42asd" as 42.  We accept
1000.17 as 1000 in integer context.
This is a big deal, it's not a minor detail.

> > And I insist that much like you said people can catch
> > E_RECOVERABLE_ERROR and turn ignore it, they can do the same with
> > E_CASE - except now they won't *have* to learn about this new behavior
> > unless they explicitly want to.  While you think it may not be strict
> > enough for some people, and I think it'd be too strict for others -
> > the consistency argument should make the decision between the two
> obvious.
>
> E_CAST is problematic. Having something we encourage some people to make
> an error and some people not to means that in some cases your library
works
> fine and rosy in other people's environments and sometimes it crashes
your

That's the point.  Many people will not consider this an error, myself
included, and I suspect that also Rasmus and Andi who created the language
concept for the language many many years ago.  PHP doesn't consider it to
be an error today across the language.
Can you explain how a library that works for you won't work for someone
else?

The code inside the library will ALWAYS get valid input, in both options.
Always.  There's no difference.  If it misbehaves, it will be because of
the supplied argument - and it will be clear to the user.  Much like in
most of the cases when an API doesn't work right, it's because it's not
being used correctly and not because of a bug in the implementation.

> Also, it's worth pointing out that people will have to learn the new
behaviour
> anyway; no matter how we do scalar type hints, we don't currently have
them,
> and once implemented, everyone will have to get used to their existence
(and
> probably the fact they will raise E_RECOVERABLE_ERROR).

Of course they'd have to learn something new - the new syntax at the very
least.  But they wouldn't have to learn something new and inconsistent.

> > Also, I tend to agree with Stas that we can consider to do
> > E_RECOVERABLE_ERROR on the obviously 'bogus' conversions - like array
> > or object to int.  But E_RECOVERABLE_ERROR on simple data loss is
> > radically inconsistent with the rest of PHP.
> >
> > Sorry, I introduced hinting into PHP;  I intentionally did not add
> > typing for scalars as it goes against the fundamentals of the
> > language, and I fought this off back in 2008, 2010 and mildly also in
> > 2012.  Call me persistent :)
> >
> > FWIW, I think the distance between where you and I stand is not that
> > big - and if we go in the direction of E_CAST for data loss across the
> > board (any implicit casts, not just in type hints), and
> > E_RECOVERABLE_ERROR for completely broken type conversions - this is a
> > big win for PHP, beyond just type hints.
>
> I really don't like E_CAST for the reasons mentioned above. If it's a
glorified
> E_NOTICE, it's pointless,

It's not, not at all.  It helps you clean your code from these issues *IF*
you care about them, and it doesn't bug others who don't.  E_NOTICE's and
E_STRICT work remarkably well - I know many people who choose to ignore
them, and many people who wouldn't deploy code before it's 100% clean of
them.  While I'm sure you have an opinion on what this setting should be
(and I might even be able to guess it), PHP's philosophy was letting the
users (developers) choose.

Ultimately it seems you dislike a very fundamental concept in PHP, that
scalar types are 'transient' and can convert without notice depending on
the context.  You also don't seem to be too fond of the 'notice/strict'
type errors :)  I can understand that, but nonetheless, the former is a
very basic fundamental part of PHP and we shouldn't add features that go
against it, and the latter is a concept that's been serving us well for
years.

Zeev