Question about adding !function_identifier

  105048
April 3, 2019 16:07 mo.mu.wss@gmail.com ("M. W. Moe")
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
April 3, 2019 16:20 pollita@php.net (Sara Golemon)
On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe wss@gmail.com> wrote:

> 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
April 3, 2019 16:27 mo.mu.wss@gmail.com ("M. W. Moe")
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.



On Wed, Apr 3, 2019 at 9:20 AM Sara Golemon <pollita@php.net> wrote:

> On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe wss@gmail.com> wrote: > >> 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 >
  105052
April 3, 2019 16:42 rowan.collins@gmail.com (Rowan Collins)
On Wed, 3 Apr 2019 at 17:27, M. W. Moe wss@gmail.com> wrote:

> 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
April 3, 2019 16:52 mo.mu.wss@gmail.com ("M. W. Moe")
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 collins@gmail.com>
wrote:

> On Wed, 3 Apr 2019 at 17:27, M. W. Moe wss@gmail.com> wrote: > > > 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] >
  105054
April 3, 2019 16:56 ik@stijnpeeters.nl (Stijn Peeters)
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 collins@gmail.com>  
wrote:  

> On Wed, 3 Apr 2019 at 17:27, M. W. Moe wss@gmail.com> wrote: > > > 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] >
  105055
April 3, 2019 17:00 claude.pache@gmail.com (Claude Pache)
> Le 3 avr. 2019 à 18:52, M. W. Moe 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
April 3, 2019 17:10 mo.mu.wss@gmail.com ("M. W. Moe")
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 pache@gmail.com> wrote:

> > > > Le 3 avr. 2019 à 18:52, M. W. Moe 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 > >
  105057
April 3, 2019 17:13 mo.mu.wss@gmail.com ("M. W. Moe")
The argument sits there.

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

On Wed, Apr 3, 2019 at 10:10 AM M. W. Moe wss@gmail.com> wrote:

> 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 pache@gmail.com> > wrote: > >> >> >> > Le 3 avr. 2019 à 18:52, M. W. Moe 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 >> >>
  105060
April 3, 2019 18:42 rowan.collins@gmail.com (Rowan Collins)
On 03/04/2019 18:13, M. W. Moe wrote:
 > 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
April 3, 2019 19:31 mo.mu.wss@gmail.com ("M. W. Moe")
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 collins@gmail.com>
wrote:

> On 03/04/2019 18:13, M. W. Moe wrote: > > 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] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  105062
April 3, 2019 19:56 rowan.collins@gmail.com (Rowan Collins)
On 03/04/2019 20:31, M. W. Moe wrote:
> 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
April 3, 2019 20:24 george.banyard@gmail.com ("G. P. B.")
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
April 3, 2019 20:29 mo.mu.wss@gmail.com ("M. W. Moe")
Thanks!

On Wed, Apr 3, 2019 at 1:24 PM G. P. B. banyard@gmail.com> wrote:

> 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
April 4, 2019 00:47 php-lists@koalephant.com (Stephen Reay)
> On 4 Apr 2019, at 03:29, M. W. Moe wss@gmail.com> wrote: > > Thanks! > >> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. banyard@gmail.com> wrote: >> >> 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 >>
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
April 4, 2019 08:58 benjamin.morel@gmail.com (Benjamin Morel)
> > 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. On Thu, 4 Apr 2019 at 02:48, Stephen Reay <php-lists@koalephant.com> wrote:
> > > > On 4 Apr 2019, at 03:29, M. W. Moe wss@gmail.com> wrote: > > > > Thanks! > > > >> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. banyard@gmail.com> > wrote: > >> > >> 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 > >> > > 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. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  105075
April 4, 2019 15:17 pollita@php.net (Sara Golemon)
> 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
April 4, 2019 20:43 rowan.collins@gmail.com (Rowan Collins)
On 04/04/2019 16:17, Sara Golemon wrote:
> 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
April 5, 2019 08:57 robehickman@gmail.com (Robert Hickman)
> > 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
April 5, 2019 09:37 rowan.collins@gmail.com (Rowan Collins)
On Fri, 5 Apr 2019 at 09:57, Robert Hickman <robehickman@gmail.com> wrote:

> > > > 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. >
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
April 5, 2019 10:30 robehickman@gmail.com (Robert Hickman)
> > 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
April 5, 2019 11:11 rowan.collins@gmail.com (Rowan Collins)
On Fri, 5 Apr 2019 at 11:30, Robert Hickman <robehickman@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]
  105107
April 5, 2019 11:41 robehickman@gmail.com (Robert Hickman)
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 collins@gmail.com> wrote:
> > On Fri, 5 Apr 2019 at 11:30, Robert Hickman <robehickman@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]
  105108
April 5, 2019 12:15 rowan.collins@gmail.com (Rowan Collins)
On Fri, 5 Apr 2019 at 12:42, Robert Hickman <robehickman@gmail.com> wrote:

> 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.
I think you're misunderstanding the problem: it's not that the *programmer* doesn't know the types, it's that the *analysis tool* doesn't know them, because the programmer hasn't told it, and currently has no way to tell it. To be confident the code was type safe, it would have to look like this: function foo(callable): int { return $bar(); } ....and every call to it would have to be analysable back to a function explicitly declared as returning int. The same applies to exception checking: you'd need syntax for "accept any callable that never throws", or "any callable that only throws descendants of FooException or BarException". Then you end up with this kind of fun: function curryish(callable<(int, float): int throws FooException|BarException> $callback): callable<(float): int throws FooException|BarException> { return fn($x) => $callback(42, $x); } Regards, -- Rowan Collins [IMSoP]
  105109
April 5, 2019 13:05 robehickman@gmail.com (Robert Hickman)
On Fri, 5 Apr 2019 at 13:15, Rowan Collins collins@gmail.com> wrote:
> > On Fri, 5 Apr 2019 at 12:42, Robert Hickman <robehickman@gmail.com> wrote: >> >> 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. > > > > I think you're misunderstanding the problem: it's not that the *programmer* doesn't know the types, it's that the *analysis tool* doesn't know them, because the programmer hasn't told it, and currently has no way to tell it. >
If the static analyser was programmable, it would be possible to provide it such information, within the scope of a single code base.
  105110
April 5, 2019 13:27 rowan.collins@gmail.com (Rowan Collins)
On Fri, 5 Apr 2019 at 14:05, Robert Hickman <robehickman@gmail.com> wrote:

> > I think you're misunderstanding the problem: it's not that the > *programmer* doesn't know the types, it's that the *analysis tool* doesn't > know them, because the programmer hasn't told it, and currently has no way > to tell it. > > > > If the static analyser was programmable, it would be possible to > provide it such information, within the scope of a single code base. >
I'm not really sure what you're suggesting; the normal way to "program" a static analyzer is to add more and richer type annotations to your code, as in the over-the-top example I gave (in reality, the analyser can deduce some of the types, and the syntax needn't be quite that ugly). The problem is that PHP has a lot of features where there is currently no way to specify types (callbacks, iterators, etc), and some where it's essentially impossible to do so in a checkable way ($$foo, $foo->$bar, etc). I'm not saying it's not possible, it's just a considerable project to rewrite a dynamic language into a statically typed one, and at the moment Hack is much further into that project than PHP, partly because it has less concern about backwards compatibility. Regards, -- Rowan Collins [IMSoP]
  105111
April 5, 2019 13:28 lester@lsces.co.uk (Lester Caine)
On 05/04/2019 14:05, Robert Hickman wrote:
>> I think you're misunderstanding the problem: it's not that the*programmer* doesn't know the types, it's that the*analysis tool* doesn't know them, because the programmer hasn't told it, and currently has no way to tell it. >> > If the static analyser was programmable, it would be possible to > provide it such information, within the scope of a single code base.
In the case of data returned from a database, the metadata for the database is another source of information relating to that data, and it would be useful if PHP had a means to access that data, but in reality this is still currently an area for developing 'a single code base' within the IDE level rather than PHP itself? The question in my mind is if there is still a place for results sets returned by a database query to simply be associative array elements or whether this is now too old fashioned and each should be an object which handle the validation functions relating to it and encapsulated in an object managing the various aspects of the query results such as errors returned and the like. In place of returning 'false' when something failed? Somewhere to hang failed returns rather than simply throwing the error in the hope that something else will deal with it? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105112
April 5, 2019 14:01 robehickman@gmail.com (Robert Hickman)
> > If the static analyser was programmable, it would be possible to > > provide it such information, within the scope of a single code base. > > In the case of data returned from a database, the metadata for the > database is another source of information relating to that data, and it > would be useful if PHP had a means to access that data, but in reality > this is still currently an area for developing 'a single code base' > within the IDE level rather than PHP itself? >
I already do this to a small extent with my code using Psalm, and intend to explore it more deeply in the future. I was just making the point that having this ability is useful, in case the PHP project were to develop a 'core' static analysis system. Specifying this information directly in the code, vs specifying it at the level of an API is, in my opinion, just an application of separation of concerns. Having an API for it allows type checking to be applied to existing dynamic code bases which make use of dynamic functionality in a statically knowable way, which cannot be expressed within the type system. And yes, I do believe that having a result set be a simple associative array is perfectly fine. I defer why to the lecture 'simple made easy', available on youtube and else ware. ..
  105114
April 5, 2019 17:02 benjamin.morel@gmail.com (Benjamin Morel)
> > 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 (...)
Features like scalar type hints, return types, property type hints, and preloading (which makes the definition of a type-hinted class available at compile time), should definitely help towards skipping a lot of runtime checks! On Fri, 5 Apr 2019 at 11:37, Rowan Collins collins@gmail.com> wrote:
> On Fri, 5 Apr 2019 at 09:57, Robert Hickman <robehickman@gmail.com> wrote: > > > > > > > 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. > > > > > 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] >
  105120
April 6, 2019 02:13 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

there is some trace of absolutism in every statements:

first;;; saying php is a highly dynamic is not not fact but a sorry ***
excuse; ain't part of engineering ; admitting php5 is a load of idiotic
mistakes yes; I like people going for reality not ideology; with facts you
can work with ideology; an infinite debate of nonsense with fanatics.

second;;; you can properly handling it without a preprocessor as people
trying hard to name it by going thru abusing
statements about static analysis; it's all about handling an exception
process properly; but it will require to break
compatibility as I mentioned previously.

Best.


On Fri, Apr 5, 2019 at 10:03 AM Benjamin Morel morel@gmail.com>
wrote:

> > > > 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 (...) > > > Features like scalar type hints, return types, property type hints, and > preloading (which makes the definition of a type-hinted class available at > compile time), should definitely help towards skipping a lot of runtime > checks! > > > On Fri, 5 Apr 2019 at 11:37, Rowan Collins collins@gmail.com> > wrote: > > > On Fri, 5 Apr 2019 at 09:57, Robert Hickman <robehickman@gmail.com> > wrote: > > > > > > > > > > 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. > > > > > > > > > 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] > > >
  105058
April 3, 2019 17:24 rowan.collins@gmail.com (Rowan Collins)
On Wed, 3 Apr 2019 at 17:52, M. W. Moe wss@gmail.com> wrote:

> 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
April 3, 2019 17:34 mo.mu.wss@gmail.com ("M. W. Moe")
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 collins@gmail.com>
wrote:

> On Wed, 3 Apr 2019 at 17:52, M. W. Moe wss@gmail.com> wrote: > > > 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] >