Re: Feedback on state of some PHP extensions, functions, etc.
| From: | Bishop Bettini | Date: | Fri, 14 Jun 2019 15:27:50 +0000 |
| Subject: | Re: Feedback on state of some PHP extensions, functions, etc. | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105927@lists.php.net to get a copy of this message | ||
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