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);
}
?>
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
>>
>>
>
