> On 2 Jan 2015, at 13:15, Marco Pivetta <ocram...@gmail.com> wrote:
> 
> The manual is wrong since it specifies a strict hint for something that is 
> `mixed`. It is still useful tho, since it's telling us "it accepts" 
> integer-ish values there. It's purely for documentation purposes though, it 
> is by far dictating the actual implementation.

It doesn’t specify a strict hint at all. If this was Java, that would be a 
“strict” hint, perhaps, but this isn’t Java. Again, the C programming language 
has weak parameter types.

> No, argument types exist to prevent mistakes: they prevent invalid values to 
> cross validation boundaries of the application. Documentation purposes are 
> purely secondary, we already have phpdoc for that.

Again, this is not true in all languages. Simply because this is the purpose of 
parameter types in one language does not mean that it is the purpose of them in 
all languages.

> Again with the manual (*sigh*): the manual comes AFTER the code has been 
> written.

So? I don’t see how that changes anything. The PHP manual’s conventions are 
well established and familiar to all PHP programmers.

Yes, it’s a manual, it’s documentation. But it has a well-established syntax 
for parameter types. Why should we deviate from it? Why wouldn’t new users be 
confused that the syntax used in the manual does something completely different 
for userland PHP code?

> The difference is that $amount must always be an integer (not integer-ish) 
> value, whereas $value must be a stringable value, and the cast would happen 
> at call-time, not at every loop (very relevant for instances of classes 
> implementing `__toString()`, as the call happens only once).

Why must $amount, before entering the body of the function, be an integer? An 
integer that was converted from a float or a string would work equally well. 
Surely, in this case, you should make both arguments strict, for consistency?

> I think the example I just gave you is very consistent, explicit and easy to 
> understand.

I don’t. I can’t understand why it’s fine to cast the second parameter, yet not 
the first. Why wouldn’t the following work? Let’s assume it follows the RFC, so 
int and string are weak type hints.

function repeat(int $amount, string $value) {
   $acc = '';
   $i = 0;

   while ($i < $amount) {
       $i += 1;
       $acc .= $value;
   }

   return $acc;
}

What’s wrong with this function now? I don’t understand why $value should be 
weakly-typed and $amount shouldn’t be. Why should there be inconsistency here?

> If there is any mental burden, it's mainly introduced by the proposed RFC, 
> whereas strict checking would remove any doubts about what $value can be.

But you’re proposing to have this RFC’s behaviour *and* have the strict 
behaviour. How is that less of a mental burden?

Thanks.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to