Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99205
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
 <269187f4-5924-a7cc-9163-40134546451f@fleshgrinder.com>
 <CAPhkiZyX1zC3W03CS6KBSgQxoWht96oOeFrAswG2jrSM2zJEPw@mail.gmail.com>
 <CA+kxMuQ5exWsJanp88bz7zTmoqtmKQ66NydqPhUgd=mPywncmA@mail.gmail.com>
 <CAPhkiZwi-Ji2LVFk46MpwHWmPxC_sBZkTiAHMZOV7qNiku9aug@mail.gmail.com>
 <CANUQDCiMfhUAeAX+3yfSkSp1vodegvVDt=ff7AWYPia_AnxQ4A@mail.gmail.com>
 <2dca6983-bbde-6042-6608-a593df2e85ed@gmx.de>
 <35177214-db24-5bc8-2020-37b2951259a2@rhsoft.net>
 <CA+kxMuRn08VyRZ7zTScDchDrnQc3D+d_zvs-qj6Ep=u+pVifOw@mail.gmail.com>
Message-ID: <13ad1065-ef32-067b-5e53-19da3eaa9f76@rhsoft.net>
Date: Fri, 26 May 2017 17:01:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <CA+kxMuRn08VyRZ7zTScDchDrnQc3D+d_zvs-qj6Ep=u+pVifOw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-CH
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: lists@rhsoft.net ("lists@rhsoft.net")



Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:
> On 26 May 2017 at 13:23, lists@rhsoft.net <lists@rhsoft.net> wrote:
>> does that also fix the issue https://bugs.php.net/bug.php?id=74394
> 
> 
> Dear Anonymous,
> 
> That "issue" is actually 3 issues.
> 
> case 1
> 
> class A {
>    public function test($a) {}
> }
> class B extends A {
>    public function test(string $a) { }
> }
> 
> This breaks LSP - because B::test doesn't accept all the things that
> A::test can accept and so is unlikely to ever be supported.

and how is that a problem?

A accepts anything
B limits it's inut to a *subset* of "anything"

> case 2
> 
> class A {
>    public function test($a) {}
> }
> 
> class B extends A {
>    public function test($a): string {}
> }
> 
> This works since return types were introduced.

but is not helpful when you introduce typehints and have to change *all* 
consumers before and at least it should be *consistent* while param 
typehints trigger warnings and return-types fatal errors

> case 3
> 
> class A {
>   public function test($a): string { }
> }
> 
> class B extends A {
>   public function test($a) {}
> }
> 
> This breaks LSP - anything that is calling A::test would only expect a
> string to be returned, but B::test can return anything so is unlikely
> to ever be supported.

and how is that a practical problem?

if i add a return-type to A it is *again a subset* of "anything" and can 
be no problem for the extending class and as a cosumer of B i do not 
need anything to know about the parent method

> Your tone of words is quite rude and dismissive of other people both
> on this list and in the bug reports. That's really not a good way to
> persuade people, but particularly so when you seem to not understand
> subtle computer science principles but instead want PHP to be
> customised for your own way of working.

i understand more than you imagine

> If you're installing Composer through an RPM and it's requiring you to
> install lots of dependencies, something has gone horribly wrong.
> Composer is a standalone phar executable which just needs a normal PHP
> environment.

you don't understand what i talk about - when i maintain the complete 
webstack with own packages *no* distribution package ever will work with 
php subpackage dependencies

> I'd strongly recommend having another go at using it, and in general
> opening yourself up to new ways of doing things rather than being rude
> to people who don't share your way of working

i have no need for composer and i just pointed out that people thinking 
"hey there is a package manager named composer and that's the new way 
everyting works" are just plain wrong

PHP is a programming language and the same way as i *never* compromise 
my environment with perl CPAN stuff or "pip" i won't for PHP

people these days seem to think having a ton of package managers 
parallel and going back to days with static linking by using 
flatpak/snap is a long term solution - it is not - but that same people 
also don't maintain servers without reinstall over decades or maintain a 
whole application stack for more the a decade without throwing it all 
alway and start from scratch every few years