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.
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
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.
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
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.
Rowan Collins
[IMSoP]
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:
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]
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:
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]
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
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.
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
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: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
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:
/**
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.
Rowan Collins
[IMSoP]
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:
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]
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]
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 argument sits there.
function handle(int $cmd, ...$arg) : int /* throw */
function !handle(int $cmd, ...$arg) : intThe 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): intyou 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 itI'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]
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]
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
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
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
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.
Quite honestly knowing that a function “throws” but not what it throws,
is useless.
Now if it were a proposal to add runtime checkedthrows FooException, BarTypeErroror similar, I could get behind.
Same here.
Thanks!
On Wed, Apr 3, 2019 at 1:24 PM G. P. B. george.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, BarTypeErroror similar, I could get behind.
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, BarTypeErroror 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:
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
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]
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.
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.
Rowan Collins
[IMSoP]
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.
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.
Rowan Collins
[IMSoP]
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?
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]
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<void, int>): 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);
}
Rowan Collins
[IMSoP]
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.
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.
Rowan Collins
[IMSoP]
I think you're misunderstanding the problem: it's not that theprogrammer doesn't know the types, it's that theanalysis 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?
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
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.
.
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!
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]
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 benjamin.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 rowan.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]