Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
Received-SPF: pass (google.com: domain of linepogl@gmail.com designates 10.236.154.168 as permitted sender) client-ip=10.236.154.168;
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
Date: Fri, 2 Mar 2012 11:27:18 +0100
Message-ID: <CAMyk_AaJ4dq7ArVQ8ouubEB0yGmARZqzaD2Axv0_3vq3+WgkeQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3040eb9a999cd504ba4006e4
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: linepogl@gmail.com (Lazare Inepologlou)

--20cf3040eb9a999cd504ba4006e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 for the syntax. There are two nice side effects I would like to
underline.


1.
Error-raising can be clearly delegated to the type juggling mechanism.
There will be no need to implement anything new here but reuse the existing
type juggling system of PHP. That would be very consistent. At the end of
the day, these two syntaxes are completely equivalent:

function foo((int) $bar) { ... }
function foo($bar) { $bar =3D (int)$bar; ... }


2.
If we put passing by reference into the picture, it is easy to see why the
following syntax should be a parsing error:

function foo((int) & $bar) {  }    // parsing error

On the contrary, were there no brackets, the resemblance to the syntax of C
would be confusing.




Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/2 Anthony Ferrara <ircmaxell@gmail.com>

> Hey all,
>
> I know given all the discussion about this topic lately, this is a hot
> topic.  But I whipped together a quick POC patch to implement scalar
> type casting for function parameters.  Let me describe it:
>
> Patch: https://gist.github.com/1947259
>
> Example:
>
> function foo( (int) $bar ) {
>    var_dump($bar);
> }
>
> foo(1); // int(1)
> foo("1"); // int(1)
> foo(1.5); // int(1)
> foo("foo"); // E_RECOVERABLE_ERROR - Expected integer
> foo(array()); // E_RECOVERABLE_ERROR
>
> Right now, I only implemented the checks for (int), but I add the
> parser constructs for (int), (float), (bool), (string) and (object)...
>
> Now, let's talk why I did what I did:
>
> Why did I use cast syntax?  Well, there are really three main reasons.
>  First off, to indicate that a cast may happen.  Second, to prevent
> needing new tokens (and hence reserved words).  And third to provide a
> distinction between a string class type hint and a string scalar type
> hint.
>
> Why did I only implement (int)?  Well, because I just wanted to build
> a quick dirty POC that can be executed to see the semantics of
> operation.  There are issues with it now, so rather than doing all the
> work to re-do it later, I just implemented int...
>
> Why implement (object)?  Because right now, there's no way to say you
> want to accept a generic object without caring about type.  So the
> (object) cast/hint would then provide that ability to accept a generic
> object.
>
> Why not implement (resource)?  Because that would require a new parser
> token, as it's not available now...
>
> How does the casting work?  Right now, it's using a copy of the same
> rules that internal functions use with zend_parse_parameters.  That
> way, it brings the operating semantics of internal functions and
> userland functions more inline with each other.
>
>
>
> So with that said, there are some (significant) issues with the patch:
>
> 1. First off, the arg checks happen before separation of the zval on
> non-referenced calls.  So that means the cast effects the original
> zval AND the argument.  Which is a no-go for a production patch.  So
> that means that the cast logic would need to be put after the zval
> split.  But we'd still want the checks first, so it's not too
> difficult to segregate, just requires deeper changes.  It's not
> difficult (that I can see yet), just more work...  Example of the
> problem:
>
> # sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =3D
> "1"; foo($a); var_dump($a);'
> int(1)
> int(1)
>
> 2.  Right now, the zend_aprse_arg_impl (
> http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
> that's used by internal functions is defined as static.  So we'd be
> copying a lot of the code back and forth.  In the production patch,
> I'd also want to re-factor that out a bit into either functions or
> macros to handle the type conversion and casting in both places.  That
> way, both systems would behave identical (or as close as possible).
>
>
> So, with that said, what do you think?  Is this something worth
> pursuing?  Are there any fundamental issues that I'm missing?  What
> else would we need to cover in a production patch and RFC?
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf3040eb9a999cd504ba4006e4--