# Declare minimum PHP version required?

- Thread: https://externals.io/message/72042
- Original archive: https://news-web.php.net/php.internals/72042
- Started by Yasuo Ohgaki on 2014-02-03T06:58:06+00:00
- Messages: 50
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/72042.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #72042 — Yasuo Ohgaki — 2014-02-03T06:58:06+00:00

URL: https://externals.io/message/72042#72042

Hi all,

I thought it might be good for us to have declaring minimum PHP version
required to execute script.
http://jp1.php.net/manual/en/control-structures.declare.php

Something like
<?php
declare(php_version>='5.6.0');
// or PHP_VERSION_ID? using = as minimum as it could be a little faster
// and no change in declare() syntax.
declare(php_version=50600);

If version mismatches, raise compile error and exit. Something like

Compile error: PHP 5.6.0 or later is required to compile script. Your PHP
version is 5.x.x.

The same thing can be done by `version_compare()` and `die()`, but it does not
make much sense executing script only to check PHP version and die,
especially for libraries. For library, it is preferred to fail when it is
included, not when it is executed. I wouldn't write `version_compare()` and
 `die()` for libraries, but I may use it if it's a declare(). If this is
adopted widely, it may help transition to higher versions hoping users to
consider compile error more seriously.

Issue would be current behavior for unsupported declaration.
$ php -r "declare(php_version=050600);"
Warning: Unsupported declare 'php_version' in Command line code on line 1
It does not raise E_ERROR, but E_WARNING.

Just an idea.
Any comments?

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72043 — Pierre Joye — 2014-02-03T07:03:42+00:00

URL: https://externals.io/message/72042#72043 · In reply to: #72042

> Just an idea.
> Any comments?

It looks like #define and #ifdef to me, which are achieved by packages
(composer), or testing using the php version constants.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org

---

## #72045 — Yasuo Ohgaki — 2014-02-03T07:07:31+00:00

URL: https://externals.io/message/72042#72045 · In reply to: #72042

Hi all,



> I thought it might be good for us to have declaring minimum PHP version
> required to execute script.
> http://jp1.php.net/manual/en/control-structures.declare.php
>
> Something like
> <?php
> declare(php_version>='5.6.0');
> // or PHP_VERSION_ID? using = as minimum as it could be a little faster
> // and no change in declare() syntax.
> declare(php_version=50600);
>
> If version mismatches, raise compile error and exit. Something like
>
> Compile error: PHP 5.6.0 or later is required to compile script. Your PHP
> version is 5.x.x.
>
> The same thing can be done by `version_compare()` and `die()`, but it does not
> make much sense executing script only to check PHP version and die,
> especially for libraries. For library, it is preferred to fail when it is
> included, not when it is executed. I wouldn't write `version_compare()` and
> `die()` for libraries, but I may use it if it's a declare(). If this is
> adopted widely, it may help transition to higher versions hoping users to
> consider compile error more seriously.
>
> Issue would be current behavior for unsupported declaration.
> $ php -r "declare(php_version=050600);"
> Warning: Unsupported declare 'php_version' in Command line code on line 1
> It does not raise E_ERROR, but E_WARNING.
>
> Just an idea.
> Any comments?
>

It may be good to have Zend API to register required library versions for
modules. For example,

declare('libxxx_version'=1.0.0);

If it does not much, failed at include.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72046 — Yasuo Ohgaki — 2014-02-03T07:10:19+00:00

URL: https://externals.io/message/72042#72046 · In reply to: #72043

Hi Pierre,



> > […]
>
> It looks like #define and #ifdef to me, which are achieved by packages
> (composer), or testing using the php version constants.


I agree.
Good packaging system should be able to handle dependency ;)
I'm not sure if this is good for us.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72048 — Marco Pivetta — 2014-02-03T07:28:51+00:00

URL: https://externals.io/message/72042#72048 · In reply to: #72045

> It may be good to have Zend API to register required library versions for
> modules. For example,
>
> declare('libxxx_version'=1.0.0);
>
> If it does not much, failed at include.
>

As Pierre said, dependency managers are indeed the current way of solving
this.

I think there was some previous discussion about cleaner usage of semver
(or similar approaches) in the extensions though, since some of the
extensions actually have inconsistent or hardly recognizable versioning.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #72052 — Stas Malyshev — 2014-02-03T07:57:44+00:00

URL: https://externals.io/message/72042#72052 · In reply to: #72042

Hi!

> The same thing can be done by `version_compare()` and `die()`, but it does not
> make much sense executing script only to check PHP version and die,
> especially for libraries. For library, it is preferred to fail when it is

Why not? That's what PHP does - executing scripts.

> included, not when it is executed. I wouldn't write `version_compare()` and

I don't understand - what is the difference? In PHP including and
executing is the same thing.

I think version_compare works just fine.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #72076 — Yasuo Ohgaki — 2014-02-03T10:55:27+00:00

URL: https://externals.io/message/72042#72076 · In reply to: #72052

Hi Stas,

On Mon, Feb 3, 2014 at 4:57 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > […]
> not
> > […]
>
> Why not? That's what PHP does - executing scripts.
>
> > […]
>
> I don't understand - what is the difference? In PHP including and
> executing is the same thing.
>
> I think version_compare works just fine.


I works, but it requires CPU time for it and evaluation is delayed at
run time, not compile time. Isn't it nice to know requirement is not met?

We may extend declare() more. For example, loaded extensions.

declare(module='pgsql,openssl');

With this, we could eliminate code like

if (!extension_loaded('foo')) {
  die('You need foo module');
}
if (!extension_loaded('bar')) {
  die('You need bar module');
}

With opcache loaded extension check may be completely skipped.

Evaluation at compile time and run time differs.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72080 — Lester Caine — 2014-02-03T11:17:46+00:00

URL: https://externals.io/message/72042#72080 · In reply to: #72076

Yasuo Ohgaki wrote:
> > […]
>
> I works, but it requires CPU time for it and evaluation is delayed at
> run time, not compile time. Isn't it nice to know requirement is not met?
>
> We may extend declare() more. For example, loaded extensions.
>
> declare(module='pgsql,openssl');
>
> With this, we could eliminate code like
>
> if (!extension_loaded('foo')) {
>    die('You need foo module');
> }
> if (!extension_loaded('bar')) {
>    die('You need bar module');
> }
>
> With opcache loaded extension check may be completely skipped.
>
> Evaluation at compile time and run time differs.

I don't see how one can eliminate checking if a module is available. I do not 
load MySQL on my systems so if someone tries to run a script requiring MySQL 
they need a warning that it's not available. The build of PHP running ensures 
that the available built in modules are of the right version, but it's the third 
party libraries that I need to ensure are compatible with the version of PHP I'm 
trying to run, and that the necessary extensions for that library are loaded. 
Stuff updated to PHP5.5 may not work on the systems that are still running 
PHP5.4 for compatibility reasons ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #72081 — Patrick Schaaf — 2014-02-03T11:28:27+00:00

URL: https://externals.io/message/72042#72081 · In reply to: #72076

Am 03.02.2014 11:56 schrieb "Yasuo Ohgaki" <yohgaki@ohgaki.net>:
>
> We may extend declare() more. For example, loaded extensions.
>
> declare(module='pgsql,openssl');
>
> With opcache loaded extension check may be completely skipped.

I like this.

It would be even more useful to me - kind of a more structured #ifdef - if

A) it would work at the block level, not failing, but eliding the block:

    declare(module='redis') {
        use redis server
    }

(instead of a class_exists check with the associated runtime overhead, both
in execution time and opcache memory usage

B) it would support testing for constants

declare(const='ADMIN_SERVER') { ... }
declare(const_false='DEVELOPMENT_SERVER') { ... }

which would really be a plus for us, using MINIT time constants provided by
the defcon extension (http://github.com/infusion/PHP-Defcon)

best regards
  Patrick

---

## #72082 — Patrick Schaaf — 2014-02-03T11:30:42+00:00

URL: https://externals.io/message/72042#72082 · In reply to: #72081

Am 03.02.2014 12:28 schrieb "Patrick Schaaf" <bof@bof.de>:
> B) it would support testing for constants
>
> declare(const='ADMIN_SERVER') { ... }
> declare(const_false='DEVELOPMENT_SERVER') { ... }
>
> which would really be a plus for us, using MINIT time constants provided
by the defcon extension (http://github.com/infusion/PHP-Defcon)

For this use case it might be useful if an extension could simply extend
declare with additional keywords, and effect that code elision as a
reaction to the keyword / check being used and done at compile time.

best regards
  Patrick

---

## #72093 — Sara Golemon — 2014-02-03T18:14:56+00:00

URL: https://externals.io/message/72042#72093 · In reply to: #72042

> I thought it might be good for us to have declaring minimum PHP version
> required to execute script.
> http://jp1.php.net/manual/en/control-structures.declare.php
>
> Something like
> <?php
> declare(php_version>='5.6.0');
> // or PHP_VERSION_ID? using = as minimum as it could be a little faster
> // and no change in declare() syntax.
> declare(php_version=50600);
>
While I like it from a formality stand-point, I have to agree with
Stas.  The is entirely doable as PHP code right now.  Include time IS
execute time.  And if you're concerned with a single integer compare
in your perf analysis, you're probably worried about the wrong thing.

-Sara

---

## #72102 — Yasuo Ohgaki — 2014-02-03T19:27:42+00:00

URL: https://externals.io/message/72042#72102 · In reply to: #72080

Hi Lester,



> Yasuo Ohgaki wrote:
>
> > […]
>
> I don't see how one can eliminate checking if a module is available. I do
> not load MySQL on my systems so if someone tries to run a script requiring
> MySQL they need a warning that it's not available. The build of PHP running
> ensures that the available built in modules are of the right version, but
> it's the third party libraries that I need to ensure are compatible with
> the version of PHP I'm trying to run, and that the necessary extensions for
> that library are loaded. Stuff updated to PHP5.5 may not work on the
> systems that are still running PHP5.4 for compatibility reasons


declare() is evaluated at compile time. It's not a usual function, but a
Zend engine directive. Therefore, it can be used for
declare(encoding='SJIS') which declare to compiler used encoding.

Since it is evaluated at compile time, run time check is not needed at all
when byte code cache is used.

There are many code out there checks if (!extention_loaded(foo')) die('You
need foo'). This is waste of CPU resources once it is checked. These
requirements for scripts may be evaluated at compile time and script runs a
little faster.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72107 — Stas Malyshev — 2014-02-03T19:42:55+00:00

URL: https://externals.io/message/72042#72107 · In reply to: #72102

Hi!

> There are many code out there checks if (!extention_loaded(foo')) die('You
> need foo'). This is waste of CPU resources once it is checked. These
> requirements for scripts may be evaluated at compile time and script runs a
> little faster.

Managing requirements is a job for package manager, like composer, not
language compiler, IMO.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #72109 — Yasuo Ohgaki — 2014-02-03T19:46:22+00:00

URL: https://externals.io/message/72042#72109 · In reply to: #72093

Hi Sara,



> 
> > […]
> While I like it from a formality stand-point, I have to agree with
> Stas.  The is entirely doable as PHP code right now.  Include time IS
> execute time.  And if you're concerned with a single integer compare
> in your perf analysis, you're probably worried about the wrong thing.


I may be worried to much, but I don't like run time environment checks
which evaluated over and over. There are many codes that checks PHP
version, loaded extension, library version, etc to make sure code works as
it should be. Perhaps, more generic form might be better

declare('requirements') {
  if (version_compare(PHP_VERSION, '5.6.0', '<')) {
     echo 'You need PHP 5.6.0 or later';
     return FALSE;
  }
  if (!extension_loaded('foo')) {
     echo 'You need foo extension';
     return FALSE;
  }
  // and so on
  return TRUE;
}

for example.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72111 — Yasuo Ohgaki — 2014-02-03T19:57:41+00:00

URL: https://externals.io/message/72042#72111 · In reply to: #72107

Hi Stas,

On Tue, Feb 4, 2014 at 4:42 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > […]
> die('You
> > […]
> runs a
> > […]
>
> Managing requirements is a job for package manager, like composer, not
> language compiler, IMO.


I agree that good package manager should manage requirements. However, once
code is installed, package manager will not check requirements. (Package
manager could be made to execute requirement checks at any time, though)
Therefore, there would be developers embed environmental checks to make
sure not to die with function not found, etc.

In addition to this, there would be SCL for RHEL7 and there are some tools
like phpenv. Installing PHP does not have to be executing PHP. Even if
there is good package manager, compile time requirement check is nice to
have. It's nice to have and it's not must have, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72125 — Lester Caine — 2014-02-03T21:22:35+00:00

URL: https://externals.io/message/72042#72125 · In reply to: #72102

Yasuo Ohgaki wrote:
> Since it is evaluated at compile time, run time check is not needed at all when
> byte code cache is used.
>
> There are many code out there checks if (!extention_loaded(foo')) die('You need
> foo'). This is waste of CPU resources once it is checked. These requirements for
> scripts may be evaluated at compile time and script runs a little faster.

And if the system you are running no longer has your 'byte code cache'? I'm 
still running eaccelerator as it's the base for all the legacy systems.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #72127 — Yasuo Ohgaki — 2014-02-03T21:31:30+00:00

URL: https://externals.io/message/72042#72127 · In reply to: #72125

Hi Lester,



> Yasuo Ohgaki wrote:
>
> > […]
>
> And if the system you are running no longer has your 'byte code cache'?
> I'm still running eaccelerator as it's the base for all the legacy systems.


I don't think type of byte code cache matters.
I could be wrong. Anyone?

BTW, if you use legacy system with legacy code, there would not be
declare('requirements') or like. If there is, you get E_WARNING.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72139 — johannes@schlueters.de — 2014-02-03T22:09:41+00:00

URL: https://externals.io/message/72042#72139 · In reply to: #72109

> I may be worried to much, but I don't like run time environment checks
> which evaluated over and over. There are many codes that checks PHP
> version, loaded extension, library version, etc to make sure code works as
> it should be. Perhaps, more generic form might be better
> 
> declare('requirements') {
>   if (version_compare(PHP_VERSION, '5.6.0', '<')) {
>      echo 'You need PHP 5.6.0 or later';
>      return FALSE;
>   }
>   if (!extension_loaded('foo')) {
>      echo 'You need foo extension';
>      return FALSE;
>   }
>   // and so on
>   return TRUE;
> }
> 

That still has to run each time the file is included.

johannes

---

## #72163 — Larry Garfield — 2014-02-04T00:34:38+00:00

URL: https://externals.io/message/72042#72163 · In reply to: #72111

> Hi Stas,
>
> On Tue, Feb 4, 2014 at 4:42 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
>
> > […]
>
>
> I agree that good package manager should manage requirements. However, once
> code is installed, package manager will not check requirements. (Package
> manager could be made to execute requirement checks at any time, though)
> Therefore, there would be developers embed environmental checks to make
> sure not to die with function not found, etc.
>
> In addition to this, there would be SCL for RHEL7 and there are some tools
> like phpenv. Installing PHP does not have to be executing PHP. Even if
> there is good package manager, compile time requirement check is nice to
> have. It's nice to have and it's not must have, though.
>
> Regards,

I have to agree with Stas and Sara on this one.  This is not the job of 
the language syntax.  This is the package manager's job; once the code 
is installed (not compiled, installed), you shouldn't be changing your 
version anyway without knowing what you're doing / verifying on a test 
system anyway.

If this were more like Javascript's "use strict", where it affected the 
parsing rules of that file, that would at least be useful (if 
potentially mind-bendingly painful for the engine; no I'm not suggesting 
we do that).  But a shortcut for if (version_compare()) die; is not 
needed, and that would be a dumb way to go about implementing version 
requirements in the first place.

--Larry Garfield

---

## #72165 — Yasuo Ohgaki — 2014-02-04T03:39:24+00:00

URL: https://externals.io/message/72042#72165 · In reply to: #72139

Hi Johannes,

On Tue, Feb 4, 2014 at 7:09 AM, Johannes Schlüter <johannes@schlueters.de>wrote:

> 
> > […]
> as
> > […]
>
> That still has to run each time the file is included.


Zend engine does not have to store byte codes of declare block as it is
compiler directive. It would be beneficial with byte code cache.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72166 — Yasuo Ohgaki — 2014-02-04T03:51:32+00:00

URL: https://externals.io/message/72042#72166 · In reply to: #72163

Hi Larry,

On Tue, Feb 4, 2014 at 9:34 AM, Larry Garfield <larry@garfieldtech.com>wrote:

> 
>
> > […]
>
> I have to agree with Stas and Sara on this one.  This is not the job of
> the language syntax.  This is the package manager's job; once the code is
> installed (not compiled, installed), you shouldn't be changing your version
> anyway without knowing what you're doing / verifying on a test system
> anyway.
>
> If this were more like Javascript's "use strict", where it affected the
> parsing rules of that file, that would at least be useful (if potentially
> mind-bendingly painful for the engine; no I'm not suggesting we do that).
>  But a shortcut for if (version_compare()) die; is not needed, and that
> would be a dumb way to go about implementing version requirements in the
> first place.


This assumption is not valid as I already wrote.
There will be SCL in RHEL7 and there are tools like phpenv.
Installing PHP does not have to be executing PHP.

Version and module requirement checks are popular and I
don't think it is dumb at all. It is dumb that if script didn't
work as it should be due to version mismatch, isn't it?

BTW, it is not a short cut of version check, but "elimination of
run time check overheads". Many people don't understand
what declare() is, it seems.

declare() is compiler directive, *NOT* a function. Thus it could
instruct what compiler should do at compile time. Since declare()
is compiler directive, compiler may omit byte code for declare
block. Therefore, run time overheads of declare block may be
eliminated with byte code cache.

Isn't checking requirements over and over a waste of resources?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72176 — Larry Garfield — 2014-02-04T06:34:03+00:00

URL: https://externals.io/message/72042#72176 · In reply to: #72166

>
> > […]
>
> This assumption is not valid as I already wrote.
> There will be SCL in RHEL7 and there are tools like phpenv.
> Installing PHP does not have to be executing PHP.

I don't know what SCL is, nor what phpenv is.  Thus "installing PHP does 
not have to be executing PHP" makes little sense to me as a sentence.

> Version and module requirement checks are popular and I
> don't think it is dumb at all. It is dumb that if script didn't
> work as it should be due to version mismatch, isn't it?

Well usually it will fatal anyway if it's written for a too-new 
version.  I know software has version checks in it; Drupal (the project 
I work on primarily) has had a version check in it for years... but in 
the installer, not in arbitrary non-installer files.

> BTW, it is not a short cut of version check, but "elimination of
> run time check overheads". Many people don't understand
> what declare() is, it seems.
>
> declare() is compiler directive, *NOT* a function. Thus it could
> instruct what compiler should do at compile time. Since declare()
> is compiler directive, compiler may omit byte code for declare
> block. Therefore, run time overheads of declare block may be
> eliminated with byte code cache.

I can think of exactly one use case for compiling or not compiling a 
given file depending on the version, and that's for function backports 
(like the old PHP_Compat library, or the backport of the password hash 
functions from PHP 5.5.)  Those are trivial enough to just wrap the 
require statement in a `version_compare()`.  Or, really, the opcode 
overhead of that compared to the size of a typical code base these days 
is probably negligible.

> Isn't checking requirements over and over a waste of resources?

Yes. So don't do it. :-)  Really, I have no clue what the use case is here.

--Larry Garfield

---

## #72183 — Yasuo Ohgaki — 2014-02-04T08:11:25+00:00

URL: https://externals.io/message/72042#72183 · In reply to: #72176

Hi Larry,

On Tue, Feb 4, 2014 at 3:34 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> 
>
> > […]
>
> I don't know what SCL is, nor what phpenv is.  Thus "installing PHP does
> not have to be executing PHP" makes little sense to me as a sentence.
>
>
Both SCL and phpenv (or like) provides multiple PHP versions installed on
the same system. Users are easily switch PHP version to be executed. SCL
allows to use multiple versions at the same time, too.


>
>  Version and module requirement checks are popular and I
> > […]
>
> Well usually it will fatal anyway if it's written for a too-new version.
>  I know software has version checks in it; Drupal (the project I work on
> primarily) has had a version check in it for years... but in the installer,
> not in arbitrary non-installer files.


For application developers, this is the way I would recommend.


>
>
>  BTW, it is not a short cut of version check, but "elimination of
> > […]
>
> I can think of exactly one use case for compiling or not compiling a given
> file depending on the version, and that's for function backports (like the
> old PHP_Compat library, or the backport of the password hash functions from
> PHP 5.5.)  Those are trivial enough to just wrap the require statement in a
> `version_compare()`.  Or, really, the opcode overhead of that compared to the
> size of a typical code base these days is probably negligible.
>
>
>  Isn't checking requirements over and over a waste of resources?
> > […]
>
> Yes. So don't do it. :-)  Really, I have no clue what the use case is here.


For library developers, it's not simple like applications.
Developers would like to specify environment. However, almost all library
would not have a flag if the environment is checked or not. They may specify
supported environment in a document. However, we know that users just
ignore documents if it seems it runs OK.

Developers have 3 options
 - Do nothing. Just let it die or fail.
 - Provide compatibility check script separately.
 - Embed compatibility code in it.

First option is many libraries adopting which is not ideal, but it's good
for
performance. Second may be ignored for the same reason as documentation.
Third option is preferred way to make sure, but it may require unwanted
overheads. If package manager supports compatibility check function or
definition, it must be evaluated as packager specifies.

With declare(), it could be solved nicely with byte code cache. It's also
important that it fails when script is included, no need to evaluate it
with specified manner and/or at run time. It's as simple as including
script
and user know what's wrong immediately. Package manager could be
simpler also.

I only see Pros for this. Is there Cons? Rather than "it can be done this
way"?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72187 — Yasuo Ohgaki — 2014-02-04T09:08:32+00:00

URL: https://externals.io/message/72042#72187 · In reply to: #72076

Hi all,



> We may extend declare() more. For example, loaded extensions.
>
> declare(module='pgsql,openssl');
>
> With this, we could eliminate code like
>
> if (!extension_loaded('foo')) {
>   die('You need foo module');
> }
> if (!extension_loaded('bar')) {
>   die('You need bar module');
> }
>
> With opcache loaded extension check may be completely skipped.
>
> Evaluation at compile time and run time differs.
>

Similar thing could be achieved with new `assert()` w/o any overheads.

https://wiki.php.net/rfc/expectations

assert('version_compare(PHP_VERSION, "5.5.0", ">=")', 'You need PHP 5.5.0
or later');

Since `assert()` only accepts expression, it might be nice to have

declare('assert') {
  if (!extension_loaded('foo')) {
     echo 'You need foo module';
     return FALSE;
  }
  if (!extension_loaded('bar')) {
     echo 'You need bar module';
     return `FALSE` 
  }
  return TRUE;
}

Usual PHP code might be easier to write complex assertion.
It may be possible to share most of the new assertion code.

Just an idea.
What do you think Dmitry?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72206 — Dmitry Stogov — 2014-02-04T18:30:46+00:00

URL: https://externals.io/message/72042#72206 · In reply to: #72187

Hi Yasuo,

I don't think PHP needs new language constructs for assertions.
Actually, the code from your example may be implemented as two calls to
 `assert()`.

assert(extension_loaded('foo'), 'You need foo module');
assert(extension_loaded('bar'), 'You need bar module');

I think it's much clear then inventing new syntax.
With Joe's proposal these asserts might be completely eliminated.
And it's backward and forward compatible :)

BTW: I didn't follow all the discussion, so I may miss some points.

Thanks. Dmitry.







> Hi all,
>
> 
>
> > […]
>
> Similar thing could be achieved with new `assert()` w/o any overheads.
>
> https://wiki.php.net/rfc/expectations
>
> assert('version_compare(PHP_VERSION, "5.5.0", ">=")', 'You need PHP 5.5.0
> or later');
>
> Since `assert()` only accepts expression, it might be nice to have
>
> declare('assert') {
>   if (!extension_loaded('foo')) {
>      echo 'You need foo module';
>      return FALSE;
>   }
>   if (!extension_loaded('bar')) {
>      echo 'You need bar module';
>      return `FALSE` 
>   }
>   return TRUE;
> }
>
> Usual PHP code might be easier to write complex assertion.
> It may be possible to share most of the new assertion code.
>
> Just an idea.
> What do you think Dmitry?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

---

Next page: https://externals.io/message/72042.md?page=2