Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:
On 26 May 2017 at 13:23, li...@rhsoft.net <li...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
