# Question about adding !function_identifier

- Thread: https://externals.io/message/105048
- Original archive: https://news-web.php.net/php.internals/105048
- Started by M. W. Moe on 2019-04-03T16:07:12+00:00
- Messages: 32
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/105048.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #105048 — M. W. Moe — 2019-04-03T16:07:12+00:00

URL: https://externals.io/message/105048#105048

Hello people,

I have a quick question before any formal proposal; would it be complex to
add an exclamation mark indicatorin front a function identifier to indicate
that function throws; like the nullable question mark for types however
 without any runtime check something like a pure syntax indicator to make
the code clearer?


Have a good day.

---

## #105050 — Sara Golemon — 2019-04-03T16:20:34+00:00

URL: https://externals.io/message/105048#105050

> I have a quick question before any formal proposal; would it be complex to
> add an exclamation mark indicatorin front a function identifier to indicate
> that function throws; like the nullable question mark for types however
>  without any runtime check something like a pure syntax indicator to make
> the code clearer?
>
> If you're suggesting something with no runtime validation, then why not
simply use docblock annotations?  They're widely supported and understood
already.

Basically, what will having that syntax give you that not having it won't?

-Sara

---

## #105051 — M. W. Moe — 2019-04-03T16:27:04+00:00

URL: https://externals.io/message/105048#105051

Hello,

yes this is very true; but usually on complex design with a lot of folks
working on it you start coding before documenting;
I was thinking like c++ `nothrow` identifie (I do know does more than
informal), I am the kind of people who like languages
which are explicit before any documentation and a throw vs nothrow is an
important contextual information, it will forcibly
change the way you engage it.





> 
>
> > […]
> simply use docblock annotations?  They're widely supported and understood
> already.
>
> Basically, what will having that syntax give you that not having it won't?
>
> -Sara

---

## #105052 — Rowan Collins — 2019-04-03T16:42:39+00:00

URL: https://externals.io/message/105048#105052

> yes this is very true; but usually on complex design with a lot of folks
> working on it you start coding before documenting;
>


If it's just syntax that doesn't change behaviour, it's really just
documentation anyway, and if people are so desperate to dig into the code
that they can't write a minimal docblock (or so lazy that they won't), how
likely is it that they'll correctly add this new indicator?

If you want to be explicit, don't put off docblocks until later (writing
them before you've even implemented the function can be a great way of
clarifying your design), and use an IDE or CI tool that will tell you when
they're missing or incorrect.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #105053 — M. W. Moe — 2019-04-03T16:52:33+00:00

URL: https://externals.io/message/105048#105053

Hello,

not documenting at first is not really a question of laziness or so, as
things are still moving around
you absolutely  need this agility; a good design layout between theory and
stable state will refactored
discussed a thousand times; that what I expect from engineers; filling the
gaps between assumptions
and reality.

And for me-self throw vs no throw is important language information and
part of internal behaviors;
to clarify, for instance, would be more useful to have such indicator
rather than having having
abstract and interface which are cumbersome; same as the extra public
keyword; you can do without
especially with the new traits construct.

Best.


On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins <rowan.collins@gmail.com>
wrote:

> 
>
> > […]
>
>
> If it's just syntax that doesn't change behaviour, it's really just
> documentation anyway, and if people are so desperate to dig into the code
> that they can't write a minimal docblock (or so lazy that they won't), how
> likely is it that they'll correctly add this new indicator?
>
> If you want to be explicit, don't put off docblocks until later (writing
> them before you've even implemented the function can be a great way of
> clarifying your design), and use an IDE or CI tool that will tell you when
> they're missing or incorrect.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

---

## #105054 — Stijn Peeters — 2019-04-03T16:56:24+00:00

URL: https://externals.io/message/105048#105054

I think the issue here is that there is no functional difference between an exclamation mark prefix and a docblock attribute, and the latter has the advantage of being more explicit, not requiring changes to the language syntax itself, and being an already-existing standard. 

Of course things may move around during the development process, but I don't really see how you can't move around the docblocks with the functions they belong to... A decent IDE will make this easy and can also use the @throws tag to provide the contextual information you're looking for, again, without having to change the language itself.

Best,
Stijn



Op 3 april 2019 bij 18:52:58, M. W. Moe (mo.mu.wss@gmail.com) schreef:

Hello,  

not documenting at first is not really a question of laziness or so, as  
things are still moving around  
you absolutely need this agility; a good design layout between theory and  
stable state will refactored  
discussed a thousand times; that what I expect from engineers; filling the  
gaps between assumptions  
and reality.  

And for me-self throw vs no throw is important language information and  
part of internal behaviors;  
to clarify, for instance, would be more useful to have such indicator  
rather than having having  
abstract and interface which are cumbersome; same as the extra public  
keyword; you can do without  
especially with the new traits construct.  

Best.  


On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins <rowan.collins@gmail.com>  
wrote:  

> On Wed, 3 Apr 2019 at 17:27, M. W. Moe <mo.mu.wss@gmail.com> wrote:  
>  
> > […]
>  
>  
> If it's just syntax that doesn't change behaviour, it's really just  
> documentation anyway, and if people are so desperate to dig into the code  
> that they can't write a minimal docblock (or so lazy that they won't), how  
> likely is it that they'll correctly add this new indicator?  
>  
> If you want to be explicit, don't put off docblocks until later (writing  
> them before you've even implemented the function can be a great way of  
> clarifying your design), and use an IDE or CI tool that will tell you when  
> they're missing or incorrect.  
>  
> Regards,  
> --  
> Rowan Collins  
> [IMSoP]

---

## #105055 — Claude Pache — 2019-04-03T17:00:46+00:00

URL: https://externals.io/message/105048#105055

> Le 3 avr. 2019 à 18:52, M. W. Moe <mo.mu.wss@gmail.com> a écrit :
> 
> Hello,
> 
> not documenting at first is not really a question of laziness or so, as
> things are still moving around
> you absolutely  need this agility; a good design layout between theory and
> stable state will refactored
> discussed a thousand times; that what I expect from engineers; filling the
> gaps between assumptions
> and reality.
> 
> And for me-self throw vs no throw is important language information and
> part of internal behaviors;
> to clarify, for instance, would be more useful to have such indicator
> rather than having having
> abstract and interface which are cumbersome; same as the extra public
> keyword; you can do without
> especially with the new traits construct.
> 
> Best.

If you’re unwilling to write a docblock for some good reason, why not just use the built-in, user-extensible way that most programming languages have to add annotations without runtime effect, namely unstructured comments? Something like /* nothrow */ is both forward- and backward-compatible... Am I missing something?

—Claude

---

## #105056 — M. W. Moe — 2019-04-03T17:10:23+00:00

URL: https://externals.io/message/105048#105056

Hello,

yes this is very true, but still foreign to the language construct; empty
contextual indicators it's what
we usually do in C and assembly (it has no cost) especially on extra
sensitive code to make it short.



>
>
> > […]
> and
> > […]
> the
> > […]
>
> If you’re unwilling to write a docblock for some good reason, why not just
> use the built-in, user-extensible way that most programming languages have
> to add annotations without runtime effect, namely unstructured comments?
> Something like /* nothrow */ is both forward- and backward-compatible... Am
> I missing something?
>
> —Claude

---

## #105057 — M. W. Moe — 2019-04-03T17:13:26+00:00

URL: https://externals.io/message/105048#105057

The argument sits there.

function handle(int $cmd, ...$arg) : int /* throw */
function !handle(int $cmd, ...$arg) : int



> Hello,
>
> yes this is very true, but still foreign to the language construct; empty
> contextual indicators it's what
> we usually do in C and assembly (it has no cost) especially on extra
> sensitive code to make it short.
>
> On Wed, Apr 3, 2019 at 10:00 AM Claude Pache <claude.pache@gmail.com>
> wrote:
>
> > […]

---

## #105058 — Rowan Collins — 2019-04-03T17:24:18+00:00

URL: https://externals.io/message/105048#105058

> not documenting at first is not really a question of laziness or so, as
> things are still moving around
> you absolutely  need this agility; a good design layout between theory and
> stable state will refactored
> discussed a thousand times; that what I expect from engineers; filling the
> gaps between assumptions
> and reality.
>


I think we have different assumptions about what "documentation" means
here. I'm not saying you have to write a 500-word paragraph explaining the
theory and edge-cases in the code; just that you should write a quick
comment saying what the function expects, and what it will return, beyond
the ability of the language's syntax.

You *could* write every function like this:

function tbc(...$args) {
}

That way, you can change the visibility, the argument types, the return
types, and the name, without "documenting" it in advance. Clearly, that
would be ridiculous, so you probably actually write this:

public function convertFooToBar(Foo $foo): Bar {
}

What I mean by "documentation first" is to go a small step further and
write:

/**
 * Convert using the lookup tables
 *
 * @param Foo $foo Should only be given pre-validated Foo
 * @return Bar Will always be pre-validated
 * @throws InvalidFooTypeException
 */
public function convertFooToBar(Foo $foo): Bar {
}


This is all part of the *current* design of this function. It might change,
but if it changes, you change the docblock, just as you'd change the
signature if you realised it should actually be private, or accept a
PreValidatedFoo object, or the name is wrong.


You seem to want to do this same job, but with as few characters as
possible, and I don't really understand why, if your aim is to be explicit
and clear. If you just want to type less, use an IDE or editor with good
auto-complete support.


Regards,
-- 
Rowan Collins
[IMSoP]

---

## #105059 — M. W. Moe — 2019-04-03T17:34:30+00:00

URL: https://externals.io/message/105048#105059

Hello,

quick commenting usually ends up in a `circus`; either you enforce extra
qualifiers in term of signature or you don't encourage it
you seems not having the experience of working on the same code base with
basically literally dozen of people which can at
some point intervene; this is reality, this not wrong or bad; you deal with
it.

We are a shop where people are using terminal emulators; vim or emacs not
cumbersome IDEs or for some not even a window manager
; reality; you deal with it. Moreover an exception state is not really like
a status; this is an internal language behavior, should
be carried by the syntax even if informal, anyhow could evolve over time.


On Wed, Apr 3, 2019 at 10:24 AM Rowan Collins <rowan.collins@gmail.com>
wrote:

> 
>
> > […]
> and
> > […]
> the
> > […]
>
>
> I think we have different assumptions about what "documentation" means
> here. I'm not saying you have to write a 500-word paragraph explaining the
> theory and edge-cases in the code; just that you should write a quick
> comment saying what the function expects, and what it will return, beyond
> the ability of the language's syntax.
>
> You *could* write every function like this:
>
> function tbc(...$args) {
> }
>
> That way, you can change the visibility, the argument types, the return
> types, and the name, without "documenting" it in advance. Clearly, that
> would be ridiculous, so you probably actually write this:
>
> public function convertFooToBar(Foo $foo): Bar {
> }
>
> What I mean by "documentation first" is to go a small step further and
> write:
>
> /**
>  * Convert using the lookup tables
>  *
>  * @param Foo $foo Should only be given pre-validated Foo
>  * @return Bar Will always be pre-validated
>  * @throws InvalidFooTypeException
>  */
> public function convertFooToBar(Foo $foo): Bar {
> }
>
>
> This is all part of the *current* design of this function. It might change,
> but if it changes, you change the docblock, just as you'd change the
> signature if you realised it should actually be private, or accept a
> PreValidatedFoo object, or the name is wrong.
>
>
> You seem to want to do this same job, but with as few characters as
> possible, and I don't really understand why, if your aim is to be explicit
> and clear. If you just want to type less, use an IDE or editor with good
> auto-complete support.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

---

## #105060 — Rowan Collins — 2019-04-03T18:42:18+00:00

URL: https://externals.io/message/105048#105060

> The argument sits there.
 >
 > function handle(int $cmd, ...$arg) : int /* throw */
 > function !handle(int $cmd, ...$arg) : int


The first example is unambiguous, easy to understand by anyone with a 
basic knowledge of the language, easy to spot when reading the code, 
easy to grep for, and will be recognised as a comment by any tool for 
parsing PHP.

The second example is hard to spot, completely opaque in meaning, and 
would break any tool which didn't have it added as a feature. I'm really 
struggling to see any advantages at all, other than saving a few key 
presses.

Of course, neither documents what type of exceptions will be thrown, so 
it's a bit like documenting every return type as either "void" or 
"mixed"; which is why the more common practice would look more like this:

/** @throws InvalidFooException */
function handle(int $cmd, ...$arg): int


> you seems not having the experience of working on the same code base 
> with basically literally dozen of people which can at
> some point intervene; this is reality, this not wrong or bad; you deal 
> with it.


You're right, I haven't worked in a team that size, but if I did, I 
would expect strict coding standards that emphasise clear intent and 
documented behaviour to be absolutely essential for everyone to know 
what was going on.


> either you enforce extra qualifiers in term of signature or you don't 
> encourage it


I'm struggling to see the difference between enforcing "add an ! before 
the name if it throws" and "add a comment next to the name if it 
throws", or even "add X to the name if it throws", unless the language 
itself is going to perform some extra check.


Regards,

-- 
Rowan Collins
[IMSoP]

---

## #105061 — M. W. Moe — 2019-04-03T19:31:50+00:00

URL: https://externals.io/message/105048#105061

Hello,

you are very kind and trying hard but that's not the topic; the commenting
section suggestion was some kind of decoy or trap;
it does not address the original request and its scope; what's behind is
more fundamental; I may have a polite discussion and
argument with people; not bulls, they belong to the prairies.

and what  about ?String (cynicism)

Have a good day.

On Wed, Apr 3, 2019 at 11:42 AM Rowan Collins <rowan.collins@gmail.com>
wrote:

> 
> > […]
>
>
> The first example is unambiguous, easy to understand by anyone with a
> basic knowledge of the language, easy to spot when reading the code,
> easy to grep for, and will be recognised as a comment by any tool for
> parsing PHP.
>
> The second example is hard to spot, completely opaque in meaning, and
> would break any tool which didn't have it added as a feature. I'm really
> struggling to see any advantages at all, other than saving a few key
> presses.
>
> Of course, neither documents what type of exceptions will be thrown, so
> it's a bit like documenting every return type as either "void" or
> "mixed"; which is why the more common practice would look more like this:
>
> /** @throws InvalidFooException */
> function handle(int $cmd, ...$arg): int
>
>
> > […]
>
>
> You're right, I haven't worked in a team that size, but if I did, I
> would expect strict coding standards that emphasise clear intent and
> documented behaviour to be absolutely essential for everyone to know
> what was going on.
>
>
> > […]
>
>
> I'm struggling to see the difference between enforcing "add an ! before
> the name if it throws" and "add a comment next to the name if it
> throws", or even "add X to the name if it throws", unless the language
> itself is going to perform some extra check.
>
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]

---

## #105062 — Rowan Collins — 2019-04-03T19:56:42+00:00

URL: https://externals.io/message/105048#105062

> the commenting section suggestion was some kind of decoy or trap;
> it does not address the original request and its scope


Perhaps you could clarify what that scope is, then. As I say, I'm not 
clear what the difference is between the proposed syntax and a comment, 
unless it changes the behaviour of the language in some way.

Regards,

-- 
Rowan Collins
[IMSoP]

---

## #105063 — G. P. B. — 2019-04-03T20:24:18+00:00

URL: https://externals.io/message/105048#105063

Hello,

I don't really see the point of it as you self said this wouldn't add a
runtime check, so in what is it different to a comment?
More so reusing ! for this will, in my opinion, just lead to confusion as
people will think it negates the function, this is what
I would expect it to do at first glance.
Also comparing it to the nullable question mark is quite bizarre I find,
why not choose the ampersand for references instead?
At least it would cover the same "scope", as types have nothing to do with
how a function behaves.

Best regards

George P. Banyard

---

## #105064 — M. W. Moe — 2019-04-03T20:29:20+00:00

URL: https://externals.io/message/105048#105064

Thanks!



> Hello,
>
> I don't really see the point of it as you self said this wouldn't add a
> runtime check, so in what is it different to a comment?
> More so reusing ! for this will, in my opinion, just lead to confusion as
> people will think it negates the function, this is what
> I would expect it to do at first glance.
> Also comparing it to the nullable question mark is quite bizarre I find,
> why not choose the ampersand for references instead?
> At least it would cover the same "scope", as types have nothing to do with
> how a function behaves.
>
> Best regards
>
> George P. Banyard

---

## #105066 — Stephen Reay — 2019-04-04T00:47:49+00:00

URL: https://externals.io/message/105048#105066

> 
> 
> Thanks!
> 
> > […]

Quite honestly knowing that a function “throws” but not *what* it throws, is useless. 

Now if it were a proposal to add *runtime checked* `throws FooException, BarTypeError` or similar, I could get behind.

---

## #105069 — Benjamin Morel — 2019-04-04T08:58:54+00:00

URL: https://externals.io/message/105048#105069

>
> Quite honestly knowing that a function “throws” but not *what* it throws,
> is useless.
> Now if it were a proposal to add *runtime checked* `throws FooException,
> BarTypeError` or similar, I could get behind.


  Same here.



>
>
> > […]
> wrote:
> > […]
> as
> > […]
> with
> > […]
>
> Quite honestly knowing that a function “throws” but not *what* it throws,
> is useless.
>
> Now if it were a proposal to add *runtime checked* `throws FooException,
> BarTypeError` or similar, I could get behind.

---

## #105075 — Sara Golemon — 2019-04-04T15:17:37+00:00

URL: https://externals.io/message/105048#105075

> Quite honestly knowing that a function “throws” but not
> *what* it throws, is useless.
>
> Now if it were a proposal to add *runtime checked*
> `throws FooException, BarTypeError` or similar, I could get behind.
>
Agreed.  I use noexcept in C++ *because* it adds value.  If this proposal
were along the lines of the following (with runtime checking included),
then I could get on board:

1) function foo(): type noexcept {...}
and/or
2) function foo(): type throws(Type) {...}

I don't even expect the runtime checks would hurt the happy path much since
we already have a check for active exceptions during the function unwind,
and once we know we have an exception, we're in the sad path and an extra
millisecond to check the exception type isn't going to break the bank.

I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption. Similarly if
an exception which is not of type "Type" in (2) should do the same.  2
should (arguably) allow for union typing the way catch does.  (e.g.
 throws(Foo | Bar | Baz)

Basically, the problem with this proposal IMO is that it doesn't go nearly
far enough, and that a single character modifier is unhelpful compared to
something actually readable.

-Sara

---

## #105085 — Rowan Collins — 2019-04-04T20:43:58+00:00

URL: https://externals.io/message/105048#105085

> I would say that any exception thrown in (1) should lead to an non-zero
> exit since the program has violated an invariant assumption.


The problem with enforcing an exception contract at runtime is surely 
how to avoid the cure being worse than the disease.

The behaviour most consistent with the current language would be to 
throw an Error - this is what happens for other invariant violations 
like "null passed where an array was expected". But that doesn't really 
make any sense here: it would mean wrapping a meaningful exception in a 
generic UnexpectedExceptionError and then throwing it again, at code 
that's still not expecting it.

An immediate fatal error would be more practical, but I'm not sure what 
benefit it would bring. If the calling code has no way of catching the 
exception, it will eventually blow through the stack and become a fatal 
error anyway; but if it would eventually reach a catch block, what value 
is added by making it fatal immediately instead?

For instance:

function foo(): type nothrow {
    throw new SomethingException; // or, more likely, fail to catch one 
from a deeper call
}
function bar(): type throws ( SomethingException ) {
    throw new SomethingException;
}

try {
     foo();
     bar();
} catch ( SomethingException $e ) {
     log($e);
}

The program can clearly cope with a SomethingException and carry on; but 
because the author of foo() didn't fully test their code, it has no 
chance to and is killed outright instead.

Regards,

-- 
Rowan Collins
[IMSoP]

---

## #105099 — Robert Hickman — 2019-04-05T08:57:32+00:00

URL: https://externals.io/message/105048#105099

>
> For instance:
>
> function foo(): type nothrow {
>     throw new SomethingException;
> }

Would it be possible to analyse the call graph at compile time
(bytecode generation) and then trigger a fatal error? It wouldn't be
possible for variable functions/methods though. A separate static
analyser could do the same thing.

---

## #105104 — Rowan Collins — 2019-04-05T09:37:03+00:00

URL: https://externals.io/message/105048#105104

> > […]
>
> Would it be possible to analyse the call graph at compile time
> (bytecode generation) and then trigger a fatal error? It wouldn't be
> possible for variable functions/methods though. A separate static
> analyser could do the same thing.
>


Yes, I think we are rapidly approaching the limit where to make the
language stricter, we need an official static analysis tool, like Hack has,
rather than trying to do everything at run-time.

It might even be possible to build this into OpCache somehow, so that if
you pre-analyse your code, it will skip runtime checks that it can prove
will never fail (e.g. return type annotation on a function that always
returns literals).

The tricky part is that PHP is a highly dynamic language, so there's a lot
of cases where the analysis can only return "maybe". My understanding is
that this is what a lot of the work on Hack is doing: creating a language
which looks a lot like PHP, but doesn't have as many ambiguous cases which
can't be analysed statically.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #105105 — Robert Hickman — 2019-04-05T10:30:37+00:00

URL: https://externals.io/message/105048#105105

>
> The tricky part is that PHP is a highly dynamic language, so there's a lot
> of cases where the analysis can only return "maybe". My understanding is
> that this is what a lot of the work on Hack is doing: creating a language
> which looks a lot like PHP, but doesn't have as many ambiguous cases which
> can't be analysed statically.
>

Quite a lot of code that apparently cannot be statically analysed
could be if the static analyser was programmable. To give a simple
example:

$result = mysqli_query ($conn, 'select * from some_table');
$arr = mysqli_fetch_assoc ($result);

The contents of '$arr' cannot be known using only the data provided in
this code, however it's contents is statically knowable. 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.

I suspect this is the case for a lot of 'non analysable code', it can
only function within a known set of states, but the type system is
unaware of those states.

---

## #105106 — Rowan Collins — 2019-04-05T11:11:56+00:00

URL: https://externals.io/message/105048#105106

> 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]

---

## #105107 — Robert Hickman — 2019-04-05T11:41:48+00:00

URL: https://externals.io/message/105048#105107

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?


>
> 
>
> > […]
>
>
> 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]

---

Next page: https://externals.io/message/105048.md?page=2