Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of adamjonr@gmail.com designates 10.182.231.100 as permitted sender) client-ip=10.182.231.100;
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFrhOEkOyZb28g0hq5_=yt4XeEfxm00Te=ygivYVs497Q@mail.gmail.com>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
	<CAMyk_AaJ4dq7ArVQ8ouubEB0yGmARZqzaD2Axv0_3vq3+WgkeQ@mail.gmail.com>
	<CAAyV7nFrhOEkOyZb28g0hq5_=yt4XeEfxm00Te=ygivYVs497Q@mail.gmail.com>
Date: Fri, 2 Mar 2012 15:15:44 -0500
Message-ID: <CAJzDObeLaAcow03cri3t62ayqCu5K3-TdeT6E0hu6jcKy95mcA@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04479615d15aee04ba483d50
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: adamjonr@gmail.com (Adam Jon Richardson)

--f46d04479615d15aee04ba483d50
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

> Well, there are a few questions about the implementation:
>
> 1. *Which* type casting rules should it follow?
>
> a. Regular cast rules (like $foo = (int) $foo), where it converts
> always without error?
> b. Internal function cast rules, where it warnings on error and
> prevents execution of the function.
> c. Current type hinting rules, where if it can't convert cleanly it
> E_RECOVERABLE_ERRORS
>
> Personally, I like C the best.  Where if it is passed an invalid
> value, it attempts to cleanly convert, but errors out if it can't...
> But I can see other arguments being made...
>
> 2. Should (array) be supported?  Perhaps.  So at that point, foo(array
> $bar) would do a "strict" check, and foo((array) $bar) would attempt
> to cast.  But my question would be: what would attempt to cast mean?
> Should it error out if you pass foo(1)?  That's what the internal
> function cast rules do.  And to me that's more obvious than silently
> converting it to foo(array(1))...
>
> 3. Should references be supported?  My feeling is yes, they should.
> So if you do foo((array) &$bar), it would cast the original value (if
> possible) as well.
>
> 4. What about consistency? Well, there currently is no consistency.
> Internal function parameters behave one way, and explicit casts behave
> another.  And even more confusing implicit casts behave yet another
> way ($a + $b).  So to implement this, we'd need to be consistent with
> one of them.  Frankly, I would only want to add consistency to
> internal function parameters, since the explicit cast is not useful
> IMHO (it's identical to $bar = (int) $bar), at which point it's not
> worth adding to save only that one line.  But if we're consistent with
> internal function parameter checking, then it becomes quite useful.
> We can throw warnings on unclean conversion and prevent execution of
> the function...  That way, all function calls behave the same (as much
> as I hate the concept of warnings on type hint failure)...  So, in
> that case, function calls become an implicit cast to the type, which
> is then why the stricter error handling (without breaking the spirit
> or consistency).
>
> 5. What about BC breaks?  Well, this entire patch (up to this point)
> wouldn't require one.  it's only adding the casting functionality
> (which is not implemented today), so no problem.  Existing code would
> still function fine.
>
> Thoughts?  Should I update the patch to be more inline with what I
> said above (the implicit hints that are offered by the current
> internal function argument mechanism:
>
> # sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a = "1";
> var_dump(foo($a));'
> int(1)
>
> # sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =
> "foo"; var_dump(foo($a));'
>
> Warning: Argument 1 passed to foo() must be of the type integer,
> string given, called in Command line code on line 1 and defined in
> Command line code on line 1
>
> However, since it's not raising a terminating error, more changes
> would need to be made to the VM to check the return status of the
> argument check (which is currently ignored) to determine if to proceed
> with the function call, or just return null imediately...
>
> Thoughts?


Well, this seems like a reasonable approach (at least in terms of general
discussion.)

I would suggest option a), for if it looks like the same type of cast found
within the body of functions. I believe users will expect it to act the
same way, too. Keeping track of two different cast behaviors would add to
the likelihood of misusing one or the other. Additionally, previous
proposals have struggled due to the impedance mismatch perceived between
the proposed hinting solutions and PHP's intrinsic typing qualities.
Keeping things close to the current modus operandus seems like it gives the
proposal more chance of becoming a reality.

I would also suggest that array not be included, if only to limit the scope
of the current proposal and simplify the offering. It could always be added
later. However, if it led to an increased likelihood of being
considered/passed for some reason, then include it :)

Nice work, Anthony.

I am curious what some of the core developers who've been opposed to scalar
type hinting in the past would think of this approach. Zeev, Stas, others,
would this be worth any consideration? It seems like an approach that is
potentially more consistent with PHP's typing mechanisms.

Thoughts?

Adam

--f46d04479615d15aee04ba483d50--