Re: [RFC] Scalar Type Hints v0.2

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.collins@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 > >