Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80462
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 74.125.82.176 as permitted sender)
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>
In-Reply-To: <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQGo6gmoLPH7aNIVeHjTN7HPWATOMwFgXHbXAiinDCoCNhsVSQIuHXg7nM6/K3A=
Date: Wed, 14 Jan 2015 15:35:55 +0200
Message-ID: <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com>
To: RQuadling@gmail.com
Cc: Andrea Faulds <ajf@ajf.me>, Leigh <leight@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b343d84b020fd050c9cd1f7
Subject: RE: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: zeev@zend.com (Zeev Suraski)

--047d7b343d84b020fd050c9cd1f7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t think we=E2=80=99re ever going to get consensus.  But judgi=
ng by the
feedback to the v0.1 version, I tend to disagree that the opposers would
have blocked it.  There were certainly opposers =E2=80=93 but not that many=
 of them
as far as I could tell.  I think it stood a good chance to pass at a 2/3.
Unlike strict typing =E2=80=93 we didn=E2=80=99t even go to a vote on it, w=
hich I think is
unfortunate (and should be changed, before changing course completely as
this v0.2 suggests).



We=E2=80=99re definitely not going to have consensus on introducing both op=
tions as
per this RFC.  I for one think it=E2=80=99s the worst possible option.



Zeev





*From:* Richard Quadling [mailto:rquadling@gmail.com]
*Sent:* Wednesday, January 14, 2015 3:23 PM
*To:* Zeev Suraski
*Cc:* Andrea Faulds; Leigh; PHP Internals List
*Subject:* Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2







On 14 January 2015 at 09:41, Zeev Suraski <zeev@zend.com> wrote:

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Wednesday, January 14, 2015 11:33 AM
> To: Leigh
> Cc: PHP Internals List
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Hi Leigh,
>
> > On 14 Jan 2015, at 09:17, Leigh <leight@gmail.com> wrote:
> >
> > I really don't like this behaviour being changed at the call site. If
> > I design a function that I _know_ should only take a string, then I
> > want it to be an error if the user supplies anything else, so that
> > they know they messed up.
>
> I don=E2=80=99t like the idea of being forced to use strict (or weak) typ=
e
> checking
> because the API author decided as much.

I don't either.  But I don't like the user to do it either, it's something
that is a part of the language definition.

I completely agree with both Robert and Leigh.  I liked the v0.1 one, but
v0.2 is DOA from my point of view.  Arguably, from my POV, it's the one
option that's even worse than having strict typing exclusively.

Zeev



The issue of scalar type hinting has been around for a while, with various
proposals and RFCs, but no consensus. Each time a certain level of progress
is made, more issues arise.



It would seem that the major issues is that whatever a library/framework
developer decides, the user of that library/framework would have to develop
their application to fit. Is this such a bad thing? The comeback to that is
that PHP supports type juggling, so there is a different mechanism for
non-scalars to scalars. Fair enough.





From the lib developer's perspective, if a parameter to a function/method
is going to be treated as an integer and is expected to be an integer, then
they should be able to force/limit this just like they can when they say it
must be an array/callable/class/interface. But take into account the option
to enforce the type juggling.





I get 3 questions from this.



1 - Should the type hint restrict non matching types?

2 - When should the value be juggled to match the type hint if it is
different?

3 - Could we allow different signatures for the same method name? - A
different question entirely, but one that may be worth having in relation
to this proposal.





Whatever mechanism is used, it needs to be of zero effort for the user, but
fully understood of the effect.





I think to answer all of this, and to provide enough flexibility that
everyone can be made happy and understand the effect, I think the issues
could be resolved with the following.





1 - A type hint of 'scalar' is required.



This excludes other types (array/callable/class/interface) and would
specifically mean that no type juggling will take place as part of the
parameter passing.



If no type juggling is going to take place, why does it matter what the
type hint is? The advantage of having 'scalar' as a type hint is, as I
said, excludes non-scalars.



Now, if the method does something to the value and the value is passed by
reference, then that would need to be documented clearly.







2 - A scalar type type hint will automatically juggle. PHP is a dynamic
language and, as such, type juggling is used throughout. It shouldn't be
any different when a parameter is type hinted for scalars.







The frustration seems to be that without a way to say that this scalar will
NOT be type juggled (loose) or that it will be (strong) then we cannot move
forward.







Now, some of the comments related to this proposal (and others) is what to
do when the scalar type is of a different type to the parameter.



I think I've covered this by the use of the type hint 'scalar'.



Scalars get type juggled. Period. For good or bad. Until PHP becomes a
strongly type language, type juggling exists.



With the hinting, we can let users know that type juggling will now also
apply to parameters.



So.



<?php

// Any type.

function anyType($a){}



// Current types.

function anArray(array $b){}

function aCallable(callable $c){}

function aClass(stdclass $d){}

function anInterface(Countable $e){}



// Any scalar - not juggled.

function anyScalar(scalar $f){}



// Any scalar - juggled

function willBeJuggledToBool(bool $g){}

function willBeJuggledToString(string $h){}

function willBeJuggledToFloat(float $i){}

function willBeJuggledToInteger(integer $j){}

?>



Considering that there are no errors generated when type juggling of
scalars take place, there should be no errors when type juggling scalar
type hints for parameters.



In essence, if you are coding with scalars (ignore type hinting) and
relying on PHP to do the right thing when type juggling takes place, then
the same level of acceptance should be used when type juggling of scalar
parameters.





TL;DR; Rejecting calls to a scalar type typehinted function because the
value is of the wrong type doesn't fit with PHP's type juggling.



--=20

Richard Quadling

--047d7b343d84b020fd050c9cd1f7--