Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54B93542.8060105@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>
	<F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me>
	<6105ea99002e634373c09685310e26a6@mail.gmail.com>
	<D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me>
	<CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com>
	<54B90431.10903@gmail.com>
	<CAPhkiZzj2b40cMD7H7uHNhF-LjeUF7XVhtLspib=_3+xAV8mYQ@mail.gmail.com>
	<54B925B8.1010601@gmail.com>
	<CAPhkiZzieuye90ycWUQzcwCe2V=6M4ehnNQ6wfkcSQ6pGL1tew@mail.gmail.com>
	<54B93542.8060105@gmail.com>
Date: Fri, 16 Jan 2015 20:53:38 +0400
Message-ID: <CA+9eiLuTu+Dm13huNwyx1DAGaGHXkDFZurLWb63qRKP3Q9m8KQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b343e5c6b438a050cc7d044
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: dmitry@zend.com (Dmitry Stogov)

--047d7b343e5c6b438a050cc7d044
Content-Type: text/plain; charset=UTF-8

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
>
>

--047d7b343e5c6b438a050cc7d044--