Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58139
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Michael Morris <dmgx.michael@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
References:
	 <CAG=uTXEfTBqX7n0_zfGjB_txQFKtZXF4MOo6RHHPSRPerGeKZA@mail.gmail.com>
	 <CAKOpQSwP_VXazO1WgQgOWiKTmgiwzorg2=ii+Mdz58a=TKs6VA@mail.gmail.com>
	 <CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 27 Feb 2012 16:39:10 +0100
Message-ID: <1330357150.2159.30.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Scalar type hinting
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.

If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.

johannes

On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
> 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
> >>
> >>
>