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

From: 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

« previous php.internals (#105927) next »