Alexander Lisachenko wrote on 17/02/2015 14:21:
2015-02-17 16:35 GMT+03:00 Rowan Collins <rowan.coll...@gmail.com
<mailto:rowan.coll...@gmail.com>>:
The other alternative is to go to the other extreme, and have the
extensions scoped to a particular file, more like Perl pragmas.
Dare I say we could use the declare() syntax that everyone seems
to have an irrational hatred of?
declare(pragma=Example\DbcParserExtension);
Ouch ) Don't like this way at all, because extensions should process
all files, even if it's not marked with some hints. What I want to see
is PHP analog of Java bytecode compilers, they can transform an
original source code into specific tokens and provide custom
extensions on top of that. So, I want to choose between php.ini option
and explicit methods. Let's see another opinions.
It's interesting that you used the word "extension" there. If the hook
can only be registered for in php.ini (and it would need to be
PHP_INI_SYSTEM if you want to avoid OpCache needing to vary its cache on
different settings) then these are basically extensions which happen to
be written in PHP - you install them globally, they execute
unconditionally, and they do things which can't be done any other way.
In that case, it would maybe make more sense to make this part of the
"simplified extension API" discussed in a previous thread, rather than
exposing it to userland at all. The only abilities you'd lose are ones
which should never be used anyway, e.g. statically registering an
extension, then dynamically changing its behaviour at runtime by
altering global/static variables.
I think the same argument applies to per-file pragmas over per-install
settings, as to Dependency Injection over global state - you should be
able to reason about each module of code in isolation, reuse it in
different combinations, etc, etc. What if you want to use two different
DbC extensions on the same server, and they collide with each other?
What would the error look like if you failed to install an extension
that was required to process your source code as intended? A declare
line (or Perl's use, or Python's import) gives a clear point where that
requirement is defined.
Regards,
--
Rowan Collins
[IMSoP]
