Re: [PHP-DEV] Question about adding !function_identifier
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
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
> wrote:
>
> > On Fri, 5 Apr 2019 at 09:57, Robert Hickman
> 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]
> >
>
Re: [PHP-DEV] Question about adding !function_identifier
>
> 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 wrote:
> On Fri, 5 Apr 2019 at 09:57, Robert Hickman 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]
>
Re: [PHP-DEV] Question about adding !function_identifier
> > 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. . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 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. > 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]
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 13:15, Rowan Collins wrote:
>
> On Fri, 5 Apr 2019 at 12:42, Robert Hickman 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 12:42, Robert Hickman 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]
Re: [PHP-DEV] Question about adding !function_identifier
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 wrote:
>
> On Fri, 5 Apr 2019 at 11:30, Robert Hickman wrote:
>
> > If a static
> > analyser were programmable, it could parse the SQL query and query the
> > database to find out what keys exist in some_table. Thus it could
> > check for references to non-existing keys.
> >
>
>
> That's an interesting example, but I don't think it generalises as far as
> you think: what would a "programmable analyser" do with an array of HTTP
> headers, or query-string parameters?
>
> However, I wasn't referring to dynamic *data* like this, but rather dynamic
> behaviour in the language itself. A couple of simple examples:
>
> function foo(callable $bar): int { return $bar(); }
> function foo(iterable $bar): int { foreach ( $bar as $baz ) { return $baz;
> } }
>
> In order to analyse those, you need a) the language to offer a richer type
> system (generics, derived types, etc); and b) the programmer to make full
> use of that type system, everywhere.
>
> As soon as you have code that's missing rich type information, or use a
> truly dynamic feature, that whole section of code becomes essentially
> unchecked. That's why Hack is not only adding features for richer
> (statically analysed) type annotations, but also *removing* PHP features
> which don't work nicely with them.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 11:30, Robert Hickman 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]
Re: [PHP-DEV] Question about adding !function_identifier
> > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 09:57, Robert Hickman 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]
Re: [PHP-DEV] Question about adding !function_identifier
>
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
> 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
Re: [PHP-DEV] Question about adding !function_identifier
> > 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 wrote: > > > > On 4 Apr 2019, at 03:29, M. W. Moe wrote: > > > > Thanks! > > > >> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. > 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 > >
Re: [PHP-DEV] Question about adding !function_identifier
> On 4 Apr 2019, at 03:29, M. W. Moe wrote: > > Thanks! > >> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. 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
Re: [PHP-DEV] Question about adding !function_identifier
Thanks! On Wed, Apr 3, 2019 at 1:24 PM G. P. B. 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 >
Re: [PHP-DEV] Question about adding !function_identifier
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
Re: [PHP-DEV] Question about adding !function_identifier
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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 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 > >
Re: [PHP-DEV] Question about adding !function_identifier
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
Re: [PHP-DEV] Question about adding !function_identifier
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
wrote:
> On Wed, 3 Apr 2019 at 17:52, M. W. Moe 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]
>
Re: [PHP-DEV] Question about adding !function_identifier
On Wed, 3 Apr 2019 at 17:52, M. W. Moe 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]
Re: [PHP-DEV] Question about adding !function_identifier
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 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 > wrote: > >> >> >> > Le 3 avr. 2019 à 18:52, M. W. Moe 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 >> >>
Re: [PHP-DEV] Question about adding !function_identifier
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 wrote: > > > > Le 3 avr. 2019 à 18:52, M. W. Moe 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 > >
Re: [PHP-DEV] Question about adding !function_identifier
> Le 3 avr. 2019 à 18:52, M. W. Moe 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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@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 wrote: > On Wed, 3 Apr 2019 at 17:27, M. W. Moe 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] >
Re: [PHP-DEV] Question about adding !function_identifier
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 wrote: > On Wed, 3 Apr 2019 at 17:27, M. W. Moe 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] >
Re: [PHP-DEV] Question about adding !function_identifier
On Wed, 3 Apr 2019 at 17:27, M. W. Moe 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]
Re: [PHP-DEV] Question about adding !function_identifier
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 wrote: > On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe 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 >
Re: [PHP-DEV] Question about adding !function_identifier
On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe 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
