Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72183
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52F089DB.7000107@garfieldtech.com>
References: <CAGa2bXYHP5D70bDBhbWzE7-B0s2kgk7DmAZdFhXkLqMJQqKV5g@mail.gmail.com>
 <52EF4BF8.60005@sugarcrm.com> <CAGa2bXacCxnmcAPZjh-YgTNocMjEpu_Uoc4npfNcKVM2WA2Tow@mail.gmail.com>
 <52EF7ADA.8090001@lsces.co.uk> <CAGa2bXZPcFKgC8RiOdj1gFzr00hCDESNGf1f+RcnKJhW65DrYA@mail.gmail.com>
 <52EFF13F.4050704@sugarcrm.com> <CAGa2bXb1DQmqAkr88fqQYXLY0ES8B-AhzgyALLzW-VsHDA27TA@mail.gmail.com>
 <52F0359E.1060707@garfieldtech.com> <CAGa2bXYofT5ZBz2avKxQqDu3D_TPzqunzCzHGeaXbzJDpZnxWw@mail.gmail.com>
 <52F089DB.7000107@garfieldtech.com>
Date: Tue, 4 Feb 2014 17:11:25 +0900
Message-ID: <CAGa2bXZpe177v8r+V7GGyBpg0b+RbF_xmoOgwKYkcJDqT8SMeg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113470d229427304f19032c7
Subject: Re: [PHP-DEV] Declare minimum PHP version required?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113470d229427304f19032c7
Content-Type: text/plain; charset=UTF-8

Hi Larry,

On Tue, Feb 4, 2014 at 3:34 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> On 02/03/2014 09:51 PM, Yasuo Ohgaki 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.
>>
>
> 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

--001a113470d229427304f19032c7--