Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58131
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Received-SPF: pass (google.com: domain of dmgx.michael@gmail.com designates 10.180.107.68 as permitted sender) client-ip=10.180.107.68;
MIME-Version: 1.0
In-Reply-To: <CAKOpQSwP_VXazO1WgQgOWiKTmgiwzorg2=ii+Mdz58a=TKs6VA@mail.gmail.com>
References: <CAG=uTXEfTBqX7n0_zfGjB_txQFKtZXF4MOo6RHHPSRPerGeKZA@mail.gmail.com>
	<CAKOpQSwP_VXazO1WgQgOWiKTmgiwzorg2=ii+Mdz58a=TKs6VA@mail.gmail.com>
Date: Mon, 27 Feb 2012 09:29:33 -0500
Message-ID: <CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Scalar type hinting
From: dmgx.michael@gmail.com (Michael Morris)

What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables.  Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax

// A tolerant variable.
integer $a = 3;

// A strict variable
strict integer $b = 2;

Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype.  Raise E_WARNING?

A strict function would have the current behavior of kicking a warning
when the type hinting fails.  Otherwise, functions should be tolerant
-

function foo ( integer $a, string $b, $c ) {}

strict function foo ( integer $a, $string $b, $c ) {}

A function parameter without a datatype would be ignored.

This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed.  Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.

On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig <kris.craig@gmail.com> wrote:
> I'll try to find some time tonight to create that for ya.
>
> Once this discussion comes together a little bit more and we have at least
> a vague-ish idea what direction we're moving in, I'll also go ahead and
> create an RFC as well so we have a conceptual product to build on.
>
> --Kris
>
>
> On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal <samuel.deal@gmail.com> wrote:
>
>> Hi,
>>
>> I create a new thread to discuss about Scalar type hinting.
>>
>> Following the John Crenshaw proposed terminology:
>> > - "Strict Typing" means the super strict old C style typing that has
>> been proven to be ridiculous in this environment because of the obvious
>> problems inherent in the fact that almost every input is a string.
>> > - "Weak Typing" means types in the same sense that the PHP documentation
>> uses types (for example, the docs indicate substr(string, integer), and
>> substr(12345, "2") == "345".)
>> > - "No Scalar Typing" should be used to indicate the current system
>> (where there is no provision for hinting at scalar types.)
>>
>> Previous weak typing proposal could be found here :
>> https://wiki.php.net/rfc/typechecking
>>
>> I have no rights to edit the wiki and make a summary of previous
>> arguments, so if someone could create it...
>>
>>
>> --
>> Samuel DEAL
>> samuel.deal@gmail.com
>>
>>