Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44695
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.78.27 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=ewyyhmynq4+9rwtuGKMjNRKdgM9gY5Z05Ht0oerVrGWJEkWE4DiYsi/JkrFxIN/yzq
         WxFQ0xapcJJ2RJl7kFyKuXMwJOTWguBzm9e3WLcUMU1fzsgZiYiB9QKcx47smLc9ZL1i
         LyU2023kA/dRvf9zuXx/9VOoPorphdoNfW+TI=
MIME-Version: 1.0
In-Reply-To: <4bcbf4710907040038i1ca78419wcafb497132b1bfc2@mail.gmail.com>
References: <5A834C9A-6D1B-49B7-88E6-FF047B084AB6@pooteeweet.org>
	 <4bcbf4710907040038i1ca78419wcafb497132b1bfc2@mail.gmail.com>
Date: Sat, 4 Jul 2009 13:17:09 +0300
Message-ID: <9b3df6a50907040317t44248a98ub8f6778e9158bb7b@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] weak and strict type checking RFC
From: arvids.godjuks@gmail.com (Arvids Godjuks)

Hello Internals.

I'm a userland PHP developer, I readed all the proposals about type
hinting and did some code writing with type hinting to see how it
looks like. Well, to my understanding it's a mess if both types of
type hinting are done.

Here is an example of a function:
function calculate_age($birthday_date, $year) {}.

How to type hint it?
Strictly or softly? Really depends on the case. If you use it
somewhere deep inside your API, than it probably should be strict. But
if not? You could get your params from anythere: database (as
strings), POST or GET (again strings), $year can be simply date('Y')
as a string or just some value from config as int. So what we see is
that strict type hinting is just too much here. Weak type hinting is
more appropriate. But do we need it at all? If I get my data from POST
or GET i'll certanly do a validation on them - trim the $year and
check it for is_numeric, $birthday_date will be checked by preg_match
to de a valid date format and then will be checked by checkdate() if
it's valid date. That leaves even weak type hinting without any real
work. If I get it from database, I'll just pass it to function,
because that data is validated and contains proper values - in this
case strict type hints will give an error for $year, because it's a
string from database and soft will just make a conversion to int so it
would happen earlier that calculations.

Strict type hint's are useless in works with database results. And
mostly in WEB we work with database results and data from GET/POST or
other sources like XML, JSON API's and so on. There data is always as
strings. Do you want that data be converted to appropriate types by
userland code something like this?
$res = $mysqli->query($sql);
if ($res && $res->num_rows) {
    while ($row = $res->fetch_assoc()) {
        foreach ($row as $k => $v) {
            if (is_numeric($v)) {
                $row[$k] = (int)$v;
            }
        }
    }
}
// Now we can use strict type hints!

Looks like it's the weak type hinting that will be used in most cases.

The question I have what will be in such case with weak type hints?:
function test(array $data) {}
test(1);

For me that should be an error, but the PHP mechanics of type
conversions should convert that 1 to array(1). Same with objects. In
object or array case most people probably will want a big error so
they could investigate there is a bug and fix it. But with strings and
integers/floats I'd prefer just silent type conversion. But you people
like consistency and I'd predict you would do int to array conversion
with weak type hinting, same as string to int/float.

A little bit messy, but I believe you got the point. My IMHO is that
a). There can't be a consistent way for all type conversions b).
Strict type hinting is out of the question.