Feedback on state of some PHP extensions, functions, etc.

php.internals

Girgias

7 years ago
Hello internal, I've been going through the documentation again to remove mentions of PHP 4 and found some extensions, functions, etc. on which I'd like to know the state of them and if it would be wise to deprecate them. I know I've thrown in some function aliases again, but only those which I think wouldn't have widespread usage. If those should still be kept in your opinion please let me know. The list are more rough notes that I took while reading the doc so if something seems unclear let me know. - ob_gzhandler, it says in a note that zlib.output_compression <https://www.php.net/manual/en/zlib.configuration.php#ini.zlib.output-compression> is preferred. [1] Moreover, it is poorly documented - the enable_dl directive, it is said that "This deprecated feature *will* certainly be *removed* in the future." [x] is this the case already? addressed in the Deprecation for 7.4 draft RFC [2] - ini_alter an alias of ini_set [3] - Deprecate the mode argument in zip_entry_open as it is ignored and always "*rb*" [4] - Deprecate the use_shortnames argument of openssl_csr_get_public_key as it is ignored [5] - odbc_do — Alias of odbc_exec() ; odbc_field_precision — Alias of odbc_field_len() <https://www.php.net/manual/en/function.odbc-field-len.php> - rewinddir returns null on success and false on failure which is an odd behavior but I suppose it was kept like that due to BC concerns. - The FILE_USE_INCLUDE_PATH constant in the Filesystem extension being an integer makes it unusable with strict types for file_get_contents() [6] however it is also used for a flag argument where it can be combined with other constants with a binary OR [7] [8]. Should this be just considered a Doc Bug? - The Enchant extension is bundled with PHP as of PHP 5.3 [9] however it seems its license is LGPL-2.1 [10] isn't this clashing with the PHP License? - PharData::setAlias, PharData::setDefaultStub and PharData::setStub always throw PharException <https://www.php.net/manual/en/class.pharexception.php> [11] [12] [13] - user_error — Alias of trigger_error() in the Error Handling extension - show_source — Alias of highlight_file() <https://www.php.net/manual/en/function.highlight-file.php> in Misc Functions - GLOB_AVAILABLE_FLAGS is used internally to check for malformed glob flags [14] but it isn't really documented [15] [16] - Deprecate the NoRewindIterator class in the SPL extension as it seems pretty useless [17] - stream_register_wrapper — Alias of stream_wrapper_register() <https://www.php.net/manual/en/function.stream-wrapper-register.php> in Stream Extension - Deprecate the stream_set_timeout function in favour of stream_select as " This function doesn't work with advanced operations like stream_socket_recvfrom() <https://www.php.net/manual/en/function.stream-socket-recvfrom.php>, use stream_select() <https://www.php.net/manual/en/function.stream-select.php> with timeout parameter instead" [18] - Change print return's type from int to void as it always returns 1 [19] to mimic echo [20] or maybe mimic printf's behavior i.e. the length of the string printed [21] - Deprecate the ftp_site function in favour of ftp_raw as ftp_site() does not return the response from the server which isn't really practical as can be seen on these two notes [22][23] - ftp_quit — Alias of ftp_close() <https://www.php.net/manual/en/function.ftp-close.php> - Unbundle the NSAPI Extension (if this is already the case, there is doc error in the membership state of the extension) as it seems obsolete in this day and age as it handles Sun/Netscape servers [24] - socket_getopt — Alias of socket_get_option() and socket_setopt — Alias of socket_set_option() <https://www.php.net/manual/en/function.socket-set-option.php> - Unbundle the XML-RPC extension as it is considered experimental [25] Best regards George P. Banyard [1] https://www.php.net/manual/en/function.ob-gzhandler.php [x] https://www.php.net/manual/en/info.configuration.php [2] https://wiki.php.net/rfc/deprecations_php_7_4 [3] https://www.php.net/manual/en/function.ini-alter.php [4] https://www.php.net/manual/en/function.zip-entry-open.php [5] https://www.php.net/manual/en/function.openssl-csr-get-public-key.php [6] https://www.php.net/manual/en/function.file-get-contents.php [7] https://www.php.net/manual/en/function.file-put-contents.php [8] https://www.php.net/manual/en/function.file.php [9] https://www.php.net/manual/en/enchant.installation.php [10] https://github.com/AbiWord/enchant [11] https://www.php.net/manual/en/phardata.setalias.php [12] https://www.php.net/manual/en/phardata.setdefaultstub.php [13] https://www.php.net/manual/en/phardata.setstub.php [14] https://github.com/php/php-src/blob/master/ext/standard/dir.c#L192 [15] https://www.php.net/manual/en/filesystem.constants.php [16] https://www.php.net/manual/en/function.glob.php [17] https://www.php.net/manual/en/class.norewinditerator.php [18] https://www.php.net/manual/en/function.stream-set-timeout.php#refsect1-function.stream-set-timeout-notes [19] https://www.php.net/manual/en/function.print.php [20] https://www.php.net/manual/en/function.echo.php [21] https://www.php.net/manual/en/function.printf.php [22] https://www.php.net/manual/en/function.ftp-site.php#86838 [23] https://www.php.net/manual/en/function.ftp-site.php#26907 [24] https://www.php.net/manual/en/book.nsapi.php [25] https://www.php.net/manual/en/intro.xmlrpc.php

Bishop Bettini

7 years ago
On Wed, Jun 12, 2019 at 11:35 AM G. P. B. <george.banyard@gmail.com> wrote:
> - PharData::setAlias, PharData::setDefaultStub and PharData::setStub > always throw PharException > <https://www.php.net/manual/en/class.pharexception.php> [11] [12] [13] > [11] https://www.php.net/manual/en/phardata.setalias.php > [12] https://www.php.net/manual/en/phardata.setdefaultstub.php > [13] https://www.php.net/manual/en/phardata.setstub.php
I don't know how much this is used in the wild, but these methods exist so that a user may treat a Phar and a PharData as interface-equivalent objects independent of the phar.readonly INI setting. I lean toward leaving these no-op methods as is, but I am happy to further discuss their merit.

Girgias

7 years ago
On Wed, 12 Jun 2019 at 18:16, Bishop Bettini <bishop@php.net> wrote:
> On Wed, Jun 12, 2019 at 11:35 AM G. P. B. <george.banyard@gmail.com> > wrote: > >> - PharData::setAlias, PharData::setDefaultStub and PharData::setStub >> always throw PharException >> <https://www.php.net/manual/en/class.pharexception.php> [11] [12] [13] >> [11] https://www.php.net/manual/en/phardata.setalias.php >> [12] https://www.php.net/manual/en/phardata.setdefaultstub.php >> [13] https://www.php.net/manual/en/phardata.setstub.php > > > I don't know how much this is used in the wild, but these methods exist so > that a user may treat a Phar and a PharData as interface-equivalent objects > independent of the phar.readonly INI setting. I lean toward leaving these > no-op methods as is, but I am happy to further discuss their merit. >
This does make sense, liek said I was just going thought the doc and didn't try to see the bigger picture especially as I don't use Phar at all. Would it make sense to create an interface PharStream (or something else) on which both these object inherit? If this doesn't make sense please ignore me. On Thu, 13 Jun 2019 at 16:33, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 12.06.2019 at 17:32, G. P. B. wrote:
> - Unbundle the XML-RPC extension as it is considered experimental [25] > > I wouldn't unbundle ext/xmlrpc because it is documented as being > experimental, but rather because nobody really looks after it, we're > bundling a modified ancient version of libxmlrpc, and even the upstream > libxmlrpc-epi isn't maintained for years. >
That is also a better reason :)
> Thanks, > Christoph > > > [25] https://www.php.net/manual/en/intro.xmlrpc.php
George P. Banyard

Bishop Bettini

7 years ago
On Fri, Jun 14, 2019 at 8:15 AM G. P. B. <george.banyard@gmail.com> wrote:
> On Wed, 12 Jun 2019 at 18:16, Bishop Bettini <bishop@php.net> wrote: > > > On Wed, Jun 12, 2019 at 11:35 AM G. P. B. <george.banyard@gmail.com> > > wrote: > > > >> - PharData::setAlias, PharData::setDefaultStub and PharData::setStub > >> always throw PharException > >> <https://www.php.net/manual/en/class.pharexception.php> [11] [12] > [13] > >> [11] https://www.php.net/manual/en/phardata.setalias.php > >> [12] https://www.php.net/manual/en/phardata.setdefaultstub.php > >> [13] https://www.php.net/manual/en/phardata.setstub.php > > > > > > I don't know how much this is used in the wild, but these methods exist > so > > that a user may treat a Phar and a PharData as interface-equivalent > objects > > independent of the phar.readonly INI setting. I lean toward leaving these > > no-op methods as is, but I am happy to further discuss their merit. > > > > This does make sense, liek said I was just going thought the doc and didn't > try to see the bigger picture especially as I don't use Phar at all. > Would it make sense to create an interface PharStream (or something else) > on which both these object inherit? If this doesn't make sense please > ignore me. >
Sure, possibly. I've added this conversation to the related PHP Bug #69196 https://bugs.php.net/bug.php?id=69196

Johannes Schlueter

7 years ago
Hi, On Wed, 2019-06-12 at 17:32 +0200, G. P. B. wrote:
> - the enable_dl directive, it is said that "This deprecated > feature *will* certainly be *removed* in the future." [x] is this > the case already? addressed in the Deprecation for 7.4 draft RFC [2]
I missed that debate, but I think there is value in being able to turn of `dl()` even in CLI context. There is certainly value in having an easy switch for embed to disable this (might be some compile-time decision in that case however)
> - ini_alter an alias of ini_set [3]
15,482 hits on GitHub https://github.com/search?l=PHP&q=ini_alter&type=Code subtracting the phpt files (I wish gH code search would filter out forks ...) and files for syntax highlighters etc. this isn't much, but some productive code.
> - Change print return's type from int to void as it always returns > 1 [19] > to mimic echo [20] or maybe mimic printf's behavior i.e. the > length of the > string printed [21]
Note that `echo`'s return value isn't void, but non-existent as echo can not be used in an expression. I believe it's good if `print`'s return value is always true'ish (i.e. not returning the length) so that $a = ""; (print $a) && something_else() works. johannes

Christoph Becker

7 years ago
On 12.06.2019 at 17:32, G. P. B. wrote:
> I've been going through the documentation again to remove mentions of PHP 4 > and found some extensions, functions, etc. on which I'd like to know the > state of them and if it would be wise to deprecate them. > > I know I've thrown in some function aliases again, but only those which I > think wouldn't have widespread usage. If those should still be kept in your > opinion please let me know. > > The list are more rough notes that I took while reading the doc so if > something seems unclear let me know. > > > - The FILE_USE_INCLUDE_PATH constant in the Filesystem extension being > an integer makes it unusable with strict types for file_get_contents() [6] > however it is also used for a flag argument where it can be combined with > other constants with a binary OR [7] [8]. > Should this be just considered a Doc Bug?
I don't think there's still a bug in the docs regarding FILE_USE_INCLUDE_PATH. See the respective note for the $use_include_path parameter.
> - Unbundle the NSAPI Extension (if this is already the case, there is > doc error in the membership state of the extension) as it seems obsolete in > this day and age as it handles Sun/Netscape servers [24]
The NSAPI is removed as of PHP 7.0.0, so the docs should be fixed.
> - Unbundle the XML-RPC extension as it is considered experimental [25]
I wouldn't unbundle ext/xmlrpc because it is documented as being experimental, but rather because nobody really looks after it, we're bundling a modified ancient version of libxmlrpc, and even the upstream libxmlrpc-epi isn't maintained for years. Thanks, Christoph