In the first case:
function foo(callable $bar): int { return $bar(); }
I think the value of $bar would have to fall into a set of values
known to the programmer, or at least known at some level. The only way
I can currently think of where this would be truly unknown is if it
comes from unfiltered user data, which would be a security issue, due
to allowing arbitrary function calls.
Wordpress does something like this in it's shortcode and
'action/filter' system, The set of valid function calls in that case
would be mostly defined by all calls to 'add_action' and 'do_action'
(and related functions for shortcodes) in the core and installed
plug-ins. It may be unknown in some cases if that is controlled by
user input. As above I doubt that is truly unknown as allowing
untrusted input would be a security issue.
In the second case the iterable has to come from somewhere, so it's
content would be defined by whatever that 'somewhere' is.
Getting back to the original topic, how would 'throws' interact with
exceptions raised by the php interpreter itself?
On Fri, 5 Apr 2019 at 12:12, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> On Fri, 5 Apr 2019 at 11:30, Robert Hickman <robehick...@gmail.com> wrote:
>
> > If a static
> > analyser were programmable, it could parse the SQL query and query the
> > database to find out what keys exist in some_table. Thus it could
> > check for references to non-existing keys.
> >
>
>
> That's an interesting example, but I don't think it generalises as far as
> you think: what would a "programmable analyser" do with an array of HTTP
> headers, or query-string parameters?
>
> However, I wasn't referring to dynamic *data* like this, but rather dynamic
> behaviour in the language itself. A couple of simple examples:
>
> function foo(callable $bar): int { return $bar(); }
> function foo(iterable $bar): int { foreach ( $bar as $baz ) { return $baz;
> } }
>
> In order to analyse those, you need a) the language to offer a richer type
> system (generics, derived types, etc); and b) the programmer to make full
> use of that type system, everywhere.
>
> As soon as you have code that's missing rich type information, or use a
> truly dynamic feature, that whole section of code becomes essentially
> unchecked. That's why Hack is not only adding features for richer
> (statically analysed) type annotations, but also *removing* PHP features
> which don't work nicely with them.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
