On 11 Dec 2017 09:10, "Andreas Hennings" <andr...@dqxtech.net> wrote:
On 11 December 2017 at 09:05, Marco Pivetta <ocram...@gmail.com> wrote: > On 11 December 2017 at 08:46, Marco Pivetta <ocram...@gmail.com> wrote: > > Indeed that already exists at > > https://github.com/Roave/BetterReflection/blob/2.0.1/docs/fe > atures.md#analysing-types-from-docblocks > > - relatively new lib, so it probably didn't get noticed upfront in here. > > > Yes, parser / userland solutions exist for this purpose. > (I have seen BetterReflection) > > I just thought since this information is already available, a library > that uses reflection API should not need a userland parser to get it. > > > Unless the codebase being analyzed is trusted and not legacy > (wordpress-style) any tool based on the current reflection API is basically > a potential security issue or a set of potentially harmful side-effects. > The reason for me and James building BetterReflection was essentially that, > since the current API is flawed and not really fixable without BC breaks > (removing the side-effect), so I strongly encourage any code analysis tool > to just use the userland adapters we wrote, and only switch to core > reflection when performance is more critical than security. > These side effects would be that the class loader loads files which can break things? Yes. Reflecting over a codebase which contains even just polyfills (duplicate classes) can already lead to unexpected crashes. Reflecting over non-PSR-2 code can even lead to worse things such as starting a DB connection and performing unwanted operations.
