Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.171 as permitted sender)
Message-ID: <54B93542.8060105@gmail.com>
Date: Fri, 16 Jan 2015 15:58:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
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>
In-Reply-To: <CAPhkiZzieuye90ycWUQzcwCe2V=6M4ehnNQ6wfkcSQ6pGL1tew@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: rowan.collins@gmail.com (Rowan Collins)

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]