Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com>
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>
Date: Wed, 14 Jan 2015 15:00:11 +0100
Message-ID: <CAB6YZuzfn7LVPWtEtWfHjtomJfzye0hjM3HT+RnOzSA9TZxVkA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: RQuadling@gmail.com, Andrea Faulds <ajf@ajf.me>, Leigh <leight@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

Hello,

personally, as a language user, I really dislike the idea of both
options for scalar type hinting to be the part of the language.
Especially since you would have to declare the strict typing in each
file (if you are going by 1 class per file in a bigger project, that's
a LOT of declare directives to write in the long run) and if you'd
forgot once, it would make the calling of methods somehow
inconsistent.

I wish there was just one way to do it; I don't care if the weak or
strong variant is going to be accepted, IMHO most programmers will be
able to adapt to either of them. The weak version makes probably more
sense for PHP and how it handles scalar types (at least from userland
developer's standpoint), but either of them is better than no
typehints at all. :)

PS: Personally, I find the "scalar" typehint idea useless and cannot
find a real use case for it. Richard, would you mind giving an
example?

Regards
Pavel Kouril

On Wed, Jan 14, 2015 at 2:35 PM, Zeev Suraski <zeev@zend.com> wrote:
> I don=E2=80=99t think we=E2=80=99re ever going to get consensus.  But jud=
ging 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 ma=
ny 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,=
 which 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 =
options 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) ty=
pe
>> 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 somethin=
g
> 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 variou=
s
> proposals and RFCs, but no consensus. Each time a certain level of progre=
ss
> 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 devel=
op
> 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, th=
en
> 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 opti=
on
> 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, b=
ut
> 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 wi=
ll
> NOT be type juggled (loose) or that it will be (strong) then we cannot mo=
ve
> forward.
>
>
>
>
>
>
>
> Now, some of the comments related to this proposal (and others) is what t=
o
> 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.
>
>
>
> --
>
> Richard Quadling