I was just surprised by the current behavior :)
$ cat ops.php
<?php
function foo(string $str) {
}
foo("ops");
?>
$ sapi/cli/php -n ops.php
Catchable fatal error: Argument 1 passed to foo() must be an instance of
string, string given in ops.php on line 2
It too me time to realize what is going on :)
Thanks. Dmitry.
On Fri, Jan 16, 2015 at 6:58 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
> Andrey Andreev wrote on 16/01/2015 15:37:
>
>> With no attempt to argue, I just thought of another example, inspired
>> by the ones given in the RFC - it is fairly common for functions
>> dealing with times to only accept a UNIX timestamp or otherwise just a
>> single kind of a time unit, such as only a count of minutes or days.
>>
>> So where '7 years' is passed and and accepted when using a weak hint
>> (by truncating the trailing non-numeric characters), a strict hint on
>> the other hand may prevent the input of incorrect data (given that
>> it's not years that are expected, of course).
>>
>
> That's a nice example of the advantage, actually, thank you.
>
> However, it makes me think of another approach to the whole situation,
> which is to make more use of Value Objects (now that the implementation of
> objects is no longer a huge performance hog). Obviously, for a timestamp,
> there is the built-in DateTimeInterface, but even if there weren't, it
> would be trivial to create something which existed only for type-checking a
> kind of sub-classed integer:
>
> class UnixTimestamp { private $value; public function get_value() { return
> $this->value } public function __construct($new_value) { /* validate input
> */ } }
>
> Obviously, the validation would still need to be written, but it would be
> tucked away in the shared class, rather than pasted as boilerplate at the
> top of every function.
>
> In many situations, the type of the argument isn't really "int" or
> "string", it's "mode" (from an enum or bitmask), or "text label" (maybe
> needs translation support) etc. So a library that really wants to document
> its type system should be providing wrappers for all these value types, at
> which point it can type hint them all by class or interface anyway.
>
> Scalar type hinting falls into the in-between category of "I want my code
> to be type-safe, but using a very flat type system which makes only loose
> guarantees about the data".
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
