Declare minimum PHP version required?

Hi Larry,

On Tue, Feb 4, 2014 at 3:34 PM, Larry Garfield larry@garfieldtech.comwrote:

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.

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

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.

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

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.

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

Yasuo Ohgaki wrote:

Yes. New assert() is as efficient as declare().
I cannot wait to use new assert()!

Yasuo
Please can you explain why you think this is so essential? The only place I
can think that I would use this I ALSO need to advise the users that there
is a problem. Adding 'assert' which apparently only has use while debugging
just seems wrong. Alright I add vd() and similar myself when debugging code
rather than using a 'debugger', but if I need to test something only at
debug time then I'll just add code and remove it when I have sorted the
problem. If it is a problem which will stop the code running, then it needs
a proper response in the workflow anyway.

ADOdb and smarty both have switches to enable debugging which can be
switched on as required at runtime and I can't see any reason they would
switch to using assert instead?

Let me rephrase that in another way.

It is no rocket science to correctly setup a production server.
Disable display errors, eanble log, create error pages (404, etc.).
Anyone not being able to understand or able to actually do it has
nothing to do anywhere closed to a production server.

Cheers,

Pierre

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

Hi Lester,

Yasuo Ohgaki wrote:

Yes. New assert() is as efficient as declare().
I cannot wait to use new assert()!

Yasuo
Please can you explain why you think this is so essential? The only place
I can think that I would use this I ALSO need to advise the users that
there is a problem. Adding 'assert' which apparently only has use while
debugging just seems wrong. Alright I add vd() and similar myself when
debugging code rather than using a 'debugger', but if I need to test
something only at debug time then I'll just add code and remove it when I
have sorted the problem. If it is a problem which will stop the code
running, then it needs a proper response in the workflow anyway.

Since I'm a developer, I do not pay much attention once code hits
production. (I do care errors a lot, though. I catch all errors/exceptions
as a sign of fatal errors) Therefore, assert() is enough for me to alert
users(developers) to notify something wrong during development.

In contract, I think you pay much attention to production environment. I
think it is very important for us (PHP internal developers) also. I guess
you're dealing with a lot of end users and getting annoyed by PHP changes.
Checking requirements at compile time would be valuable for you as you may
configure PHP to display completely broken scripts for the environment.
(i.e. Display compile error)

For this use, declare() is the best solution. We might be better to think
again for your use.

ADOdb and smarty both have switches to enable debugging which can be

switched on as required at runtime and I can't see any reason they would
switch to using assert instead?

Assertion can be used to development time only checks so that programmers
notice silly mistakes, passing invalid arguments for function, range check,
type check, format check, pre/post condition check, etc. Even for ADOdb or
Smarty developers, they have conditions that should be checked only when
they are writing new code.

I like DbC in D and other languages. For example, D supports "in" as
precondition check, and "out" as post condition check.

long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
return cast(long)std.math.sqrt(cast(real)x);
}

With contract programming, caller has a responsibility to pass arguments
that meets precondition contract and callee has responsibility returns a
result that meets post condition contract. If whole program is made this
way, callee does not have to check pre/post condition at all as long as
input for program is validated
strictly. With contract programming, lower level functions does not have to
check arguments under production environment at all, thus program runs much
faster than traditional design yet it achieves robustness. (in theory.
We're better to leave some checks for fatal error especially for security
related matter)

Assertion that does not have run time overheads at all is very cool thing
for PHP developers to write robust and fast applications, especially for
developers who prefer micro frameworks. (Missing pace for PHP is pre/post
condition check, but it's much better than before and it can work round.
Comprehensive frameworks have contract via annotation, etc at user land.)

I agree that assert() may not help you much from your users asking "I got
blank screen!", but it helps developers a lot. It also may help you if your
user can change INI setting to see what's wrong.

Does this answer your question?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net