Req #69196 [Opn]: PharData should extends Phar
| From: | cmb@php.net | Date: | Tue, 19 Jan 2021 15:47:59 +0000 |
| Subject: | Req #69196 [Opn]: PharData should extends Phar | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-231652@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=69196&edit=1
ID: 69196
Updated by: cmb@php.net
Reported by: hywan@php.net
Summary: PharData should extends Phar
Status: Open
Type: Feature/Change Request
Package: PHAR related
PHP Version: 5.6Git-2015-03-06 (Git)
Block user comment: N
Private report: N
New Comment:
Just for the record, the PharData documentation has been
fixed in the meantime.
Previous Comments:
------------------------------------------------------------------------
[2019-06-14 15:27:03] bishop@php.net
Arguably, this is a documentation bug, not a Phar bug. However, it's quite surprising and, so,
I'm converting it to a feature request. A recent conversation on internals suggested making
Phar and PharData implement an interface (rather than inheriting).
See https://marc.info/?l=php-internals&m=156051452912774&w=2:
On Wed, 12 Jun 2019 at 18:16, Bishop Bettini <bishop@***> wrote:
> On Wed, Jun 12, 2019 at 11:35 AM G. P. B. <george.banyard@***>
> 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.
------------------------------------------------------------------------
[2018-08-05 01:49:58] carusogabriel@php.net
Related To: Bug #52909
------------------------------------------------------------------------
[2015-03-30 09:50:33] mike@php.net
Sure, I'm with you, but I wouldn't fix implementation of "1+2 == 3" if
documentation says "1+2 == 4". I just mean we should think about what is th right thing to
do.
------------------------------------------------------------------------
[2015-03-30 03:26:20] reeze@php.net
-- Repost.
Hi Mike,
The bug #69196 could be fixed by specify different arg info IMO.
class Phar and PharData shared the most of the implementation, we could either fix doc or fix
implementation, but as the documentation exist so long, I do prefer fix the implementation.
------------------------------------------------------------------------
[2015-03-30 03:26:20] reeze@php.net
Related To: Bug #69196
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69196
--
Edit this bug report at https://bugs.php.net/bug.php?id=69196&edit=1