I don’t think we’re ever going to get consensus. But judging by the feedback to the v0.1 version, I tend to disagree that the opposers would have blocked it. There were certainly opposers – 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 – we didn’t 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’re definitely not going to have consensus on introducing both options as per this RFC. I for one think it’s the worst possible option. Zeev *From:* Richard Quadling [mailto:rquadl...@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 <z...@zend.com> wrote: > -----Original Message----- > From: Andrea Faulds [mailto:a...@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 <lei...@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’t like the idea of being forced to use strict (or weak) type > 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. -- Richard Quadling
