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
>
> 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
> > 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
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
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
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
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
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
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
>
> 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
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
>
>
> 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
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
> 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
>
> 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
Hello @Stephen Reay,
yes I have that in my, I was thinking about reusing the `throw` keyword and
re-contextualizing it à la use
function handle(int $cmd, ...$args) : int throw(legit, error) /*
Throws only those else triggers runtime error */
{ return -1; }
function handle(int
> 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
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
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
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
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
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
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
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
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
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 à
> 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
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
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
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
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
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
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
33 matches
Mail list logo
