Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83776
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain margaine.com from 209.85.223.175 cause and error)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLup3jEPcQaNbEQXQ8js0t9-thVRG8fCXHScL3K=aU20Ow@mail.gmail.com>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
	<CAAyV7nE+JJPr4iRiFfJg74UVZ_c6HieOmpPQWe6zwnY==m7Zhw@mail.gmail.com>
	<CAAyV7nGOh7FgkbkPGwALmU4SDOs=LvkijAPJeNcG3qrMo7-z-Q@mail.gmail.com>
	<CAAyV7nFfzaw=M0En4_3Lt5MYQ7H+ePCzFOuM4wndehxJER7NXQ@mail.gmail.com>
	<CA+9eiLuuH7v4Vvf8iDzvh=vho9mdPUpvSVHwuP6+JdNVkqLS9A@mail.gmail.com>
	<CA+9eiLup3jEPcQaNbEQXQ8js0t9-thVRG8fCXHScL3K=aU20Ow@mail.gmail.com>
Date: Wed, 25 Feb 2015 13:33:26 +0100
Message-ID: <CABRjmp-OpHuM+o0NoU-jv6e24xPbue9R4A0jT1JSiZY8m1pw4A@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>, Anthony Ferrara <ircmaxell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013d06e891720c050fe8d715
Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: florian@margaine.com (Florian Margaine)

--089e013d06e891720c050fe8d715
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Le 25 f=C3=A9vr. 2015 13:31, "Dmitry Stogov" <dmitry@zend.com> a =C3=A9crit=
 :
>
> anyone may tell, what this will print without running :)
>
> main.php
> =3D=3D=3D=3D=3D=3D=3D=3D
> <?php
> declare(strict_types=3D1)
> include "a.php";
> include "b.php";
> var_dump(foo("5"));
> ?>
>
> a.php
> =3D=3D=3D=3D=3D
> <?php
> declare(strict_types=3D0)
> function foo(string $a): string {
>     bar($a);
>     return $a;
> }
> ?>
>
> b.php
> =3D=3D=3D=3D=3D
> <?php
> declare(strict_types=3D1)
> function bar(int &$a) {
>     var_dump($a);
> }
> ?>

No error. The declare is per-file.

>
> Thank. Dmitry.
>
> On Wed, Feb 25, 2015 at 3:19 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>
> > Hi Anthony,
> >
> > Few notes:
> >
> > - first of all, it would be great to split the voting questions: 2/3 -
> > implement scalar type hinting + 1/2 - in addition add strict type
hinting
> > as you propose. I think, the concept of run-time declare() switch is no=
t
> > designed well. It just affects VM and JITed code in negative way,
because
> > in each function we will have to handle both options
> >
https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054=
389ad750ce9a9f5895cd6d27800fR3762
> > and also set additional flag on each call
> >
https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054=
389ad750ce9a9f5895cd6d27800fR2802
> > .
> >
> > - resource type hint may be useful in the same way as all other types
> >
> > - it may make sense not to disable bool/int/float/string classes at all=
.
> > we may just don't allow them in type hints. This will break less
> > applications.
> >
> > Thanks. Dmitry.
> >
> >
> >
> >
> > On Sat, Feb 21, 2015 at 6:35 PM, Anthony Ferrara <ircmaxell@gmail.com>
> > wrote:
> >
> >> All,
> >>
> >> I have updated the RFC to re-target 7.0.
> >>
> >> I have also added a new behavior:
> >>
> >> Currently, if you install an error handler that returns true, you can
> >> bypass type checking in userland functions.
> >>
> >> set_error_handler(function() { return true; });
> >> function foo(int $abc) {
> >>     var_dump($abc);
> >> }
> >> foo("test"); // string(4) "test"
> >>
> >> This is obviously a problem for strict typing. Therefore, I am
> >> proposing that strict mode bypass function execution in this case.
> >>
> >> The current proposal for engine exceptions would eliminate the need
> >> for this behavior. Therefore I documented the behavior, but am holding
> >> off on the implementation until the engine exceptions vote concludes
> >> (if it fails, the behavior documented in the RFC would be
> >> implemented).
> >>
> >> Thanks
> >>
> >> Anthony
> >>
> >> On Fri, Feb 20, 2015 at 4:09 PM, Anthony Ferrara <ircmaxell@gmail.com>
> >> wrote:
> >> > All,
> >> >
> >> >> An interesting point was brought up related to block mode:
> >> >> https://twitter.com/drrotmos/status/568540722586107904
> >> >>
> >> >> Namely that generated file caches may need the ability to switch
block
> >> >> mode on-and-off.
> >> >>
> >> >> I'm considering making the change to add that. If that happens,
> >> >> declare must be the outermost block, and no non-declare blocks woul=
d
> >> >> be allowed in the outermost scope of the file:
> >> >>
> >> >> <?php
> >> >> declare(strict_types=3D1) {
> >> >>     //...
> >> >> }
> >> >> declare(strict_types=3D0) {
> >> >>     //...
> >> >> }
> >> >>
> >> >> Having trailing code or code outside of the declare would be a
compile
> >> error.
> >> >>
> >> >> <?php
> >> >> declare(strict_types=3D1) {
> >> >>     //...
> >> >> }
> >> >> foo(); // compile error
> >> >>
> >> >> This behaves consistent with namespace block-mode today (though the
> >> >> strict type declaration would be required to be outside the
namespace
> >> >> block).
> >> >>
> >> >> I'm considering adding it, as it's a valid use-case. What do you
think?
> >> >
> >> > So, I ran into a snag while doing this.
> >> >
> >> > It turns out that in the parser implementation of declare is not
going
> >> > to allow it without significant restructuring (including a lot of
> >> > validation in the compiler):
> >> >
> >> > declare_statement:
> >> > statement { $$ =3D $1; }
> >> > | ':' inner_statement_list T_ENDDECLARE ';' { $$ =3D $2; }
> >> > ;
> >> >
> >> > So in block mode, declare supports inline, block and named-block
mode:
> >> >
> >> > declare(...) foo();
> >> > declare(...) {
> >> >     foo();
> >> > }
> >> > declare(...):
> >> >     foo();
> >> > enddeclare;
> >> >
> >> > The problem with this is that namespace declarations can only happen
> >> > in top_statement (along with some other statements).
> >> >
> >> > That leaves two options to support multiple modes per file:
> >> >
> >> > 1. Allow in top-level only:
> >> >
> >> > declare(strict_types=3D1);
> >> > namespace Foo {
> >> > }
> >> > declare(strict_types=3D0);
> >> > namespace Bar {
> >> > }
> >> >
> >> > 2. inside of the namespace:
> >> > namespace Foo {
> >> >     declare(strict_types=3D1);
> >> > }
> >> > namespace Bar {
> >> > }
> >> >
> >> > The problem with the first is clarity (it's easy to miss a declare
and
> >> > not understand that the mode has changed). We pinned declare to the
> >> > top of the file for clarity. I'm not sure this use-case is worth
> >> > breaking that clarity.
> >> >
> >> > The problem with the second is more subtle. With the current
> >> > parser+compiler, that declare would affect the entire file. It would
> >> > take pretty significant changes and restructuring of the parser to
> >> > effect.
> >> >
> >> > We could drop declare() all together and go with something like a
> >> > namespace modifier:
> >> >
> >> > strict namespace Foo {
> >> > }
> >> > namespace Bar {
> >> > }
> >> >
> >> > But I don't think it's worth it to conflate those two together.
Though
> >> > if we did, the syntax "strict namespace;" would be supported for
> >> > non-namespaced strict code.
> >> >
> >> > So in the end, my conclusion is that while it would be nice to
support
> >> > the "compiled file" use-case fully, it's not worth it from a
technical
> >> > level (the risk and degree of change required doesn't offset the
> >> > benefit of it).
> >> >
> >> > So the proposal will remain unchainged and not support the block
> >> > syntax (or changing the mode mid-file).
> >> >
> >> > Thanks
> >> >
> >> > Anthony
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >

Cheers,
Florian Margaine

--089e013d06e891720c050fe8d715--