Hi,
Le 25 févr. 2015 13:31, "Dmitry Stogov" <dmi...@zend.com> a écrit :
>
> anyone may tell, what this will print without running :)
>
> main.php
> ========
> <?php
> declare(strict_types=1)
> include "a.php";
> include "b.php";
> var_dump(foo("5"));
> ?>
>
> a.php
> =====
> <?php
> declare(strict_types=0)
> function foo(string $a): string {
> bar($a);
> return $a;
> }
> ?>
>
> b.php
> =====
> <?php
> declare(strict_types=1)
> 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 <dmi...@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 not
> > 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-3054389ad750ce9a9f5895cd6d27800fR3762
> > and also set additional flag on each call
> >
https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR2802
> > .
> >
> > - 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 <ircmax...@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 <ircmax...@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 would
> >> >> be allowed in the outermost scope of the file:
> >> >>
> >> >> <?php
> >> >> declare(strict_types=1) {
> >> >> //...
> >> >> }
> >> >> declare(strict_types=0) {
> >> >> //...
> >> >> }
> >> >>
> >> >> Having trailing code or code outside of the declare would be a
compile
> >> error.
> >> >>
> >> >> <?php
> >> >> declare(strict_types=1) {
> >> >> //...
> >> >> }
> >> >> 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 { $$ = $1; }
> >> > | ':' inner_statement_list T_ENDDECLARE ';' { $$ = $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=1);
> >> > namespace Foo {
> >> > }
> >> > declare(strict_types=0);
> >> > namespace Bar {
> >> > }
> >> >
> >> > 2. inside of the namespace:
> >> > namespace Foo {
> >> > declare(strict_types=1);
> >> > }
> >> > 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
