Re: Question about adding !function_identifier

From: Date: Sat, 06 Apr 2019 02:13:58 +0000
Subject: Re: Question about adding !function_identifier
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19  Groups: php.internals 
Request: Send a blank email to internals+get-105120@lists.php.net to get a copy of this message
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] > > >

« previous php.internals (#105120) next »