Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105921
MIME-Version: 1.0
References: <CAFPFaMJ8DqBgALHLE26fu1H5eqmQuRKbUpyV_0i4_1WbtYX==Q@mail.gmail.com>
 <CAEYWF=4H2X=utR0214bhzWtVMbmS_-OXPxgA1MazTaMtfo5z-g@mail.gmail.com>
In-Reply-To: <CAEYWF=4H2X=utR0214bhzWtVMbmS_-OXPxgA1MazTaMtfo5z-g@mail.gmail.com>
Date: Fri, 14 Jun 2019 14:13:02 +0200
Message-ID: <CAFPFaMKHAWRouE8RL9vaHc-E3BTv-5xk9yX=-eZYuhMUY2-BGw@mail.gmail.com>
To: bishop@php.net
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000036eb45058b4799bf"
Subject: Re: [PHP-DEV] Feedback on state of some PHP extensions, functions, etc.
From: george.banyard@gmail.com ("G. P. B.")

--00000000000036eb45058b4799bf
Content-Type: text/plain; charset="UTF-8"

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

--00000000000036eb45058b4799bf--