As an aside, having this kind of #ifdef type stuff also allows us to write
forward compatible scripts without worrying about invalid syntax breaking
older versions.
On Fri, Feb 5, 2016 at 11:20 AM, Pierre Joye <pierre....@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 2:00 AM, Davey Shafik <da...@php.net> wrote:
> > On Wednesday, February 3, 2016, Sara Golemon <poll...@php.net> wrote:
> >
> >> > I think Dan raises some interesting points, although I think
> >> zend_version()
> >> > is often used for feature detection so they try to put a zend version
> in
> >> > there to be helpful i.e. HHVM x.y.z === PHP a.b (feature-wise).
> >> >
> >> That's exactly why PHP_VERSION is faked in HHVM. Because that's how
> >> users use it. Essentially, we're treating PHP_VERSION as "PHP
> >> language specification version X.Y" So for example, hhvm 3.12.0
> >> conforms to phplang-spec 7.0.0 so it defines HHVM_VERSION to tell what
> >> it is, while PHP_VERSION exists for all those scripts that were
> >> written under the assumption that there's only one PHP runtime.
> >>
> >> I would actually suggest that if something like this RFC goes through,
> >> we formally define PHP_VERSION in exactly that way. As a language
> >> specification conformance advertisement. PHP_ENGINE_VERSION would be
> >> the build ID for the actual runtime implementation. In the case of
> >> the reference implementation, these numbers would be identical, so
> >> there would be no effective change. In the case of other
> >> implementations, they'd differ. For example on HHVM you'd have:
> >> PHP_VERSION=7.0.0, PHP_ENGINE=hhvm, PHP_ENGINE_VERSION=3.12.0
> >>
> >> All that said, I'm not convinced we *need* explicitly enumerated
> >> constants like PHP_ENGINE, but for that 0.1% of scripts that care who
> >> they're running under, it would certainly unify that detection in a
> >> useful way.
> >>
> >> To the question of "are we just replicating browser detection and all
> >> its problems?", I'd offer that perhaps the solution lies not in more
> >> constants, but in Reflection. For example:
> >>
> >> class ReflectionLanguage {
> >> public function isSupported($feature): bool;
> >> public function variableSyntaxConformance(): string;
> >> public function strictTypehints(): bool;
> >> }
> >>
> >> Some of these would be compiler constant-ish, others might be per-file
> >> (like strictTypeHints()).
> >>
> >> ^^ The above is a half-baked idea, please alter/destroy it at will.
> >>
>
> I am also really not convinced we need a PHP_ENGINE_* set of
> constants. It defeats the purpose of these constants.
>
> Each non php.net implementation could (should?) have a
> <implementation> and <implementation>_<version> constants, for
> instance, HHVM and HHVM_VERSIONS_* constants. These constants can then
> be used to do the required work-around for bugs or to use
> implementation specific features.
>
> > Unfortunately Sara, the types of things you generally have to work around
> > are minor things, like differences in DOM, or the inability to
> json_encode
> > DateTimeImmuteable
> >
> > I do however like the idea of feature detection - I wonder if perhaps we
> > could do something where it's done at compile time and therefore
> minimally
> > impacts runtime?
>
> This could be what you actually need. A #ifdef equivalent for PHP. I
> remember a discussion about adding these features to the core to allow
> to enable/disable portions of a script at the parsing/compilation
> level. Doing so allows mixing codes being valid for various
> implementations inside a same file. It is especially important for
> features using syntax not compatible with a php.net's PHP
> specification (for instance).
>
> I am not very keen about that either as I prefer to use separate
> files. However it seems to be where we could move forward for these
> kind of needs? parser/compilation time constants or expression (like
> HAVE_FOO in C for example but only defined by the respective engine
> and maybe extensions) as well as at runtime (as normal PHP constants).
> Just a thought :)
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
