On Wed, 12 Jun 2019 at 18:16, Bishop Bettini <bis...@php.net> wrote: > On Wed, Jun 12, 2019 at 11:35 AM G. P. B. <george.bany...@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 <cmbecke...@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
