Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75608
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <0476c27fc2a44f715ed50052e47a3b1a@mail.gmail.com>
Date: Wed, 16 Jul 2014 23:12:09 +0100
Cc: Stas Malyshev <smalyshev@sugarcrm.com>,
 Andrey Andreev <narf@devilix.net>,
 Rowan Collins <rowan.collins@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <9141893E-2DC7-437D-A684-CA5ACA2F7D33@ajf.me>
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> <0476c27fc2a44f715ed50052e47a3b1a@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)


On 16 Jul 2014, at 22:42, Zeev Suraski <zeev@zend.com> wrote:

> 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?

Someone relies on E_CAST not being fatal. Someone wanting strictness =
makes an error handler making it fatal. Bam, an awful lot of code =
breaks. E_CAST is a terrible idea if we want software interoperability. =
We can=92t have it both ways; type hints must be either strict or not =
strict, if they=92re conditionally strict by environment then we will =
destroy our ecosystem.

Of course, we could just make it a glorified E_NOTICE, but then what=92s =
the point? E_NOTICE already exists.

> 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.

Right. The code inside the library will, sure. The point is that the =
library will now crash the program because it wasn=92t written with a =
strictly-interpreted E_CAST in mind.

> 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.

It=92s inconsistent anyway. Type hints don=92t act like zpp does, unless =
you want me to make them emit E_WARNING and return NULL.

> 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.

As I=92ve explained earlier, letting them choose to make this fatal =
would be a horrible, horrible idea.

> 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.

Nope, I have zero problem with this basic feature. I may have in the =
past, sure, but I have come to like PHP=92s weak typing.

Also, they *don=92t* universally convert without notice, they only do =
when they fit a certain set of conditions. This RFC just makes userland =
type hints (which much of the community apparently wants to be fully =
strict?) have a slightly tighter ruleset that=92s more logical, if =
somewhat inconsistent with the rest of PHP.

> You also don't seem to be too fond of the 'notice/strict'
> type errors :)

E_NOTICE makes sense, I just don=92t think it=92s the right approach for =
type hints.

(Though speaking of which, the default object casting handler=92s =
behaviour of just emitting a notice instead of actually failing is =
really weird. Why is that an E_NOTICE? What on earth is the failure case =
for, then? Surely it=92s the caller=92s job to emit the notice?)

> 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.

This is obviously a matter of opinion, but I really don=92t think this =
RFC goes against that. This RFC encourages automatic type conversion, =
it=92s just slightly less lenient than zpp is to help write less buggy =
software. I suppose it fits the existing mould, where internal functions =
are really tolerant and won=92t make much fuss (a mere E_WARNING and =
NULL) while userland type hints are much more draconian.
--
Andrea Faulds
http://ajf.me/