Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44705
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <E4A1DAB31B3C423B8506C4C81178F2F2@pc>
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>,
	"Paul Biggar" <paul.biggar@gmail.com>
Cc: "PHP Internals" <internals@lists.php.net>
References: <5A834C9A-6D1B-49B7-88E6-FF047B084AB6@pooteeweet.org> <af54caaf0907040705x27ce9362v303ab74a5db62eb4@mail.gmail.com> <9B8C39B7-A5F8-4E61-BD7E-2069E584290D@pooteeweet.org>
Date: Sat, 4 Jul 2009 21:33:35 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] weak and strict type checking RFC
From: sv_forums@fmethod.com ("Stan Vassilev")


>> I can't see the difference between your proposal and the conclusion I
>> reached yesterday?
>>
>> (which was that there is a near consensus around strict checks by
>> default, with casts allowed with some syntax).
>
> Well to me it Sounded like you wanted to Rely on Standard Type  juggling 
> and what i am proposing is more strict than that. More over i  am Not 
> convinced that strict should Be the Default.
>
> Regards,
> Lukas

Just wanted to note the weak string check is the same as the strict one in 
the RFC since it appears to be incomplete. It should encompass any type that 
can cast to a string. That includes any scalar, and also objects with 
__toString method.

Also if this will be introduced, it needs to account for mixed type 
arguments, such as null/bool/int  or null/numeric etc. The RFC doesn't 
mention null at all leaving me to assume null is always allowed, no matter 
what.

I'm a supporter of strict typing for languages in general, however, in *PHP* 
in particular, strict checks don't make sense to me, given its current 
behavior.

This is a language where summing up an integer and a string can result in a 
float. API authors will start assuming strictness from their clients that is 
hard to achieve, and in the end result in peppering function/method calls 
with explicit type casting on each argument. We do not want that, I suppose.

There is one type of check that can be added right now, however, while this 
discussion continues:

function add_user(scalar name, scalar phone_number, scalar age) {}

I think we can all agree, if we can check for a class and array, then 
checking for a scalar is a natural constraint. It's both strict and weak at 
the same time since it's generic enough not to need that separation. Scalar 
here is defined by the same rules as is_scalar(), but also allows null as a 
passed value to be consistent with the other check types.

Regards,
Stan Vassilev