Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58548
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
Received-SPF: pass (google.com: domain of linepogl@gmail.com designates 10.236.184.167 as permitted sender) client-ip=10.236.184.167;
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGFMWfa4jdxcbDs_0rN2VbFCKU3a-P6cb3Ht3WYhduzXQ@mail.gmail.com>
References: <CAAyV7nEKRsY8ib-rrN6_f1SWLi-jdMeSyMe4MLO6RGzHDkym8A@mail.gmail.com>
 <CAMyk_AaJ4dq7ArVQ8ouubEB0yGmARZqzaD2Axv0_3vq3+WgkeQ@mail.gmail.com>
 <CAAyV7nFrhOEkOyZb28g0hq5_=yt4XeEfxm00Te=ygivYVs497Q@mail.gmail.com>
 <CAJzDObeLaAcow03cri3t62ayqCu5K3-TdeT6E0hu6jcKy95mcA@mail.gmail.com> <CAAyV7nGFMWfa4jdxcbDs_0rN2VbFCKU3a-P6cb3Ht3WYhduzXQ@mail.gmail.com>
Date: Sat, 3 Mar 2012 16:16:38 +0100
Message-ID: <CAMyk_Aa+CJSsvTT8fUCWrR-Y4c71WZ5JdZbbFM-e++yykdrJUg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Adam Jon Richardson <adamjonr@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf303f6acc2c4f8304ba582fed
Subject: Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
From: linepogl@gmail.com (Lazare Inepologlou)

--20cf303f6acc2c4f8304ba582fed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> To be honest, I'm not as sold on this version (I built it as a POC, but t=
o
> see how useful it is). It feels like it's not doing "enough". All it real=
ly
> does is save 6 characters.
>

Personally, I think it saves much more characters (,,,in the
documentation).

And I think, that's enough. Nothing more is needed here. If we want to
expand further on, I believe that the type casting system should be
enhanced with custom casting functions. The other proposal that you've made
fits perfectly here. Would you like to test them combined?

Another point of expansion is to have something similar for object types.
However, this requires first the introduction of custom casting rules for
objects types as well. Maybe in the future.

Great work.

Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/3 Anthony Ferrara <ircmaxell@gmail.com>

> Hey all,
>
> Here's a much more robust and updated patch (actually, it seems good
> to go to me, but needs significant review)...
> https://gist.github.com/1963999
>
> One potential issue is that it requires an API change to
> zend_verify_arg_type (which appears to only be called in zend_vm_def.h
> - and by generation zend_vm_execute.h)...  Otherwise, it's functional
> from my perspective...
>
> Here's what's implemented:
>
> The following cast syntaxes to the parameter type hints:
> (int)
> (float)
> (bool)
> (string)
> (array)
> (object)
>
> Basically, they behave exactly as the normal cast works.  So it won't
> error except in odd edge cases (for example, passing StdClass object
> into (string)...
>
> So, based on that:
>
> function ((int) $i) {}
>
> is identical to:
>
> function ($i) {
>    $i =3D (int) $i;
> }
>
> Additionally, the last 2 are a bit more interesting, as they will cast
> it to an array/object if necessary.
>
> To be honest, I'm not as sold on this version (I built it as a POC,
> but to see how useful it is).  It feels like it's not doing "enough".
> All it really does is save 6 characters.
>
> Instead, I think I'd rather see it check for a clean cast, and at
> least throw an error on unclean cast (casting (int) "foo" in this
> context).  However, that's not how the current cast handler works, so
> that's not what this does.
>
> Any feedback?
>
> Thanks,
>
> Anthony
>
>
> On Fri, Mar 2, 2012 at 3:15 PM, Adam Jon Richardson <adamjonr@gmail.com>
> wrote:
> > 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 =3D (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 =3D (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 =3D "1=
";
> >> var_dump(foo($a));'
> >> int(1)
> >>
> >> # sapi/cli/php -r 'function foo((int) $bar) { return $bar; } $a =3D
> >> "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 gener=
al
> > 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 th=
e
> > likelihood of misusing one or the other. Additionally, previous proposa=
ls
> > 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 i=
s
> > potentially more consistent with PHP's typing mechanisms.
> >
> > Thoughts?
> >
> > Adam
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf303f6acc2c4f8304ba582fed--