Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58781
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH5SkZw2rSsqp5rYvfWtqCmQK6P+vU67zOgPiZ6sZ+Xedw@mail.gmail.com>
References: <CAJRMtAGqZCWThbZVztGN3-FyQ4MkJAs=uO_V-6pUCy9q2aAaZw@mail.gmail.com>
	<CAKOpQSyas7HSDXD5bftK9o18ucYAfQvxRtTUjYOgRSv_4nY-9A@mail.gmail.com>
	<CAJWj5+EQhhYDTh8DHwv2N4pk8FQybX3P5H292BGixbHSLB7k3A@mail.gmail.com>
	<CAAyV7nGQFrMoneDKvr0s1djOOkjn6rMj6PJcuB0842eA8EefOw@mail.gmail.com>
	<52.38.15021.3A1E65F4@pb1.pair.com>
	<4F570EBB.6030103@sugarcrm.com>
	<60744d7ea642fe03c7110502a3f4276a@mohiva.com>
	<CAAyV7nGZdq+TYU3eiQXj5CtEkRs84u_oOXRB7m+RNseU1QtG+Q@mail.gmail.com>
	<CAL0xaBHC8vFSnuezWwWqsBczHZA3uvgpb+K3z3z87Mc2Gbeseg@mail.gmail.com>
	<CAJWj5+HDyBvMGN7HiHBBEswr67s=tEfsTd3mHbzfeAZRrVmB2w@mail.gmail.com>
	<CAL0xaBGAHfOSR1g4meDsJfczBTR0dOfypBjHLXGT7h9o5T7eeA@mail.gmail.com>
	<CAH-PCH5SkZw2rSsqp5rYvfWtqCmQK6P+vU67zOgPiZ6sZ+Xedw@mail.gmail.com>
Date: Thu, 8 Mar 2012 07:38:32 -0500
Message-ID: <CAAyV7nHR5RzuZ2t7keyJ_Q_Hu__WED-12Z49Mpju2GXt=k5LEw@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Simon Schick <simonsimcity@googlemail.com>, 
	internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: ircmaxell@gmail.com (Anthony Ferrara)

> AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
> solution for scalar type hints would be the unification of the scalar type
> hints with the current implementation of zend_parse_parameters.

Yeah, that's basically what we were discussing.  However, there's one
significant issue that I personally have to doing that.  in ZPP, if
you have a parameter that expects an array, and pass it an int, a
warning is raised.  But then the main body of the function is skipped
(the function isn't executed) and the control is passed back to the
calling code.

To me, that's not right at all.  That basically forces all code to use
boolean return error checking.  Even if you wanted to use exceptions,
you'd still need to wrap the calling code in an if() statement to see
if a parameter errored.  To me, that makes a *direct* port of zpp a
no-go for userland code.  Sure, it would be consistent, but it would
also lead to some very hard-to-read code if you wanted to make it
robust:

try {
    if (!foo($bar)) {
        return false;
    }
} catch (FooException $e) {
    // We want to ignore it, because we're maintaining the abstraction
and can fix it
    bar();
    return false;
}
return true;

All that code, just to make a robust function call.  Not good in my book.

> the built in php functions are "enforcing" the function signature via
> parsing the parameters through this call.
> so for example the above mentioned substr signature is substr ( string
> $string , int $start [, int $length ] )
> substr("foobar", "123"); // works like a charm
> substr("foobar", 1.5); // works, no warning/notice, although we lose
> precision here,
> substr("foobar", "123 asd"); // Notice: A non well formed numeric value
> encountered
> substr("foo", "bar"); // Warning: substr() expects parameter 2 to be long,
> string given
>
> so if we would implement the scalar typehints in a way to map the signature
> types to the zpp call, then that would mean that the scalar hints are
> consistent across the built-in functions, the documentation, and the
> dynamic nature of the language(as one could argue that the current/future
> implementation of zend_parse_parameters is in line with the dynamic
> casting/type juggling nature of php.

What I do like, is the rules for error or no error.  How it determines
if a zval can be passed to a hint of integer.  And I also like that it
casts if those rules pass...

However, I think the errors that it throws are far too kind, and can
be quite confusing and lead to difficult to defend code (meaning that
you need 10 or 15 lines of code to defensively call a piece of code).

Instead, I'd much prefer the error level be raised to
E_RECOVERABLE_ERROR, or throw an exception on those typing errors.  At
least in user type hints, and preferably in ZPP as well.  If the
function is not going to be executed, it should raise a much more
substantial error...  Otherwise *that* is going to be more confusing
than anything else IMHO...

> just my 2cents

Thanks for the reply!

Anthony