нет, L говорит, что нельзя - ты в b ухудшил предусловие

смысл L совсем в другом

а, я понял о чем он... ;) забавно

Принцип подстановки Барбары Лисков (англ. Liskov Substitution Principle, LSP) в объектно-ориентированном программировании является специфичным определением подтипа, предложенным Барбарой Лисков в 1987 году на конференции в основном докладе под названием Абстракция данных и иерархия [1]. В последующей статье[2] Лисков кратко сформулировала свой принцип следующим образом: Пусть {\displaystyle q(x)} q(x) является свойством, верным относительно объектов {\displaystyle x} x некоторого типа {\displaystyle T} T. Тогда {\displaystyle q(y)} q(y) также должно быть верным для объектов {\displaystyle y} y типа {\displaystyle S} S, где {\displaystyle S} S является подтипом типа {\displaystyle T} T. Роберт С. Мартин определил[3] этот принцип так: Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом. https://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков

сложно так

Смотри, LSP говорит, что ты можешь везде, где было a заменить на b и все должно работать. Но может не работать, ибо если у тебя где-то было $a->test(T1 $t1), то замена на $b сломает это. Вот только это не значит, что PHP должен повзолять вызывать $b->test(T1 $t1), даже забавно как тебе в голову пришло ;) Это говорит о том, что PHP не должен позволять вообще существовать такому $b, что бы его нельзя было бы подставить вместо $a

По-этому и получаем варнинг should be compatible with

вот об этом сюрпризе я говорю https://3v4l.org/TTr3T

в случае использование ide оно должно подсветить конечно

но в рантайме запустить такое можно

@miksir что сломает?

и оно работает в седьмой версии

я смог подсунуть в интерфейс посторонний тип который кстате говоря успешно обработался

посторонний тип в том примере это Surprice

все сломает ;) раз ты написал T2 в b, а не T1, значит ты явно используешь что-то специфичное для T2. Иначае бы ты T1 написал. А значит подстановка T1 вместо T2 - может привести к неожиданному поведению

вот об этом сюрпризе я говорю https://3v4l.org/TTr3T

класс B может принимать в метод m скалярную величину, а это нарушение интерфейса

класс B может принимать в метод m скалярную величину, а это нарушение интерфейса

вот это и позволяет новая фишка творить

это не сюрприз а говнокод

хотя формально оно все также реализует тот интерфейс

она просто расширяет возможности первого)

отменяет возможности первого

но это теперь не контролит язык

поставь тайп хинтинг в B и всё упадет )

класс B может принимать в метод m скалярную величину, а это нарушение интерфейса

нет, не нарушение... класс B хоть и может принимать скалярую величину, но при этом по-прежнему может принмать исходный stdClass. А значит класс B может быть использован везде, где использовался A

в шторме уже завезли и ничего не падает

а уж отработать это поведение - задача программиста

нет, не нарушение... класс B хоть и может принимать скалярую величину, но при этом по-прежнему может принмать исходный stdClass. А значит класс B может быть использован везде, где использовался A

именно)

но эта тонкая грань может выйти в рантайм

и понаворатить там всяких бед

конечно писать подобным образом код ты ссзб но все же)

ну так и не нужно ее использовать ;) она в общем введена то для BC

что за ВС?

обратная совместимость

мне вот не хватило этого когда я делал command query separation. нельзя объявить интерфейс interface iqueryhandler () { function retrive(query $q); } и имплементируя его уточнять query

ну так тут в пхп кто с опытом

а уж отработать это поведение - задача программиста

это как сделать метод в котором будет die, но с такой же сигнатурой и жаловаться, что принцип не работает)

ожидает чтобы там в magic как посторонний тип пихаешь получить type warning

а он схавает)

вообщем в java этот вопрос решен тем что есть компиляция

где оно все свалится и не пройдет в рантайм

а в пхп этого нет и может уйти

мне лично поведение до 7.2 нравилось больше чем сейчас)))

но разработчики языка думают иначе и теперь нам с этим жить

получается проблема только когда тип не указан

получается что штука довольно сырая

адекватные разработчики будут обходить эту возможность стороной

код криво выглядит, конечно, но ничего критичного не вижу

но вот неадекватные могут повеселиться)

ну неадекваты будут всегда... а вообще это задумано лишь для того, что бы переписывать на тайпхинт нижний слой в наследовании не трогая наследников

здравая мысль)

но блин жесть уже есть namespace

о чем я и начинал %)

но зачем тогда namespace ?

почему им новый код не разложить в namespace

с type hint

а потом через несколько версий не убрать старый ?

типо deprecated и тд? зачем такую сомнительную фитч?

мантейнить две версии либы? ;)

ну когда они писали первую версию либы

значит ок

а как править косяки так они что нибудь новое в язык добавляют чтобы потом когда нибудь выпиливая эту фитчу

еще несколько костылей впихнуть

потому что выпилить то что они сейчас ввели, будет еще сложней

я думаю тут заточено все под жутко кровавый энтерпрайз, который потихоньку рефакторят

а зачем им выпиливать... оно как бы не мешает

кровавый ынтерпрайз еще на php 5.3 наверно

https://3v4l.org/YaGNT

а по настоящему кровавый на 4

Всегда можно сделать “проще”. Особенно нравятся ребята которые хуярят по 1000 строк методы “потому что это проще”, тонны ifelse вложенных и тд. И для них это проще (скорее всего только в данный момент времени, а завтра им это будет уже сложно, но кого это волнует?) Главное ведь проще? Имхо что зенд (не работал, но изучал) что симфони: если писать бизнесслогику правильно, то все будет ок на протяжении долгого времени. А если писать “проще” то через год-другой кроме рвотного рефлекса ничего ваш код вызывать не будет (хотя, скорее всего он будет работать, и приносить деньги). Последующее внедрение нового функционала от фреймворков “попроще” (yii, laravel, cake codeigniter{лол, последние два еще живые?}) все труднее и труднее. ps я говорю о том, как принято писать в сообществе пользователей опредленного фреймворка. Всегда есть исключения, можно и на симфони наговнячить, и на кодигнайтере сделать все красиво

Интересно, как таких людей можно переубедить так писать?

так нифига не починили же

и нечего чинить, это правильное поведение

нет

и нечего чинить, это правильное поведение

+

нет

а что тут не правильного?

так не должно быть

да, я тебе выше несколько постов уже писал объясняя

так не должно быть

слава богу что так и есть и не работает это)

потому что это было бы вообще звездец

имхо

кстате как насчет ООП vs процедурный стиль (только не в плохом смысле этого слова)

так не должно быть

вот смотри https://3v4l.org/sE6Wq - то, что ты хочешь. А теперь представь, что работало как ты хочешь. Было у нас (new Foo())->query(new Query());, и ты заменяешь тут Foo на Bar. Что у тебя получается? Что в Bar вызывается doSomePostSpecific из Query, у которого его нет. Приплыли.

упс я чот как-то по другому хотел. в таком виде это не катит, но способ задать таким образом тайп хинтинг в пхп нужен

если замена выполнится, Bar не пропустит просто Query

и это уже нарушение L

тут не хватает... generics )

даже если не пропустит, все равно будет ошибка и программа сломается.. не суть

короче, Предусловия не могут быть усилены в подклассе.

вполне понятно... и не только про тайпхинтинг, кстати

а дженериков не хватает очень, да... мне в основном для коллекций.. если уж идем к стат типизации, хочется указывать, что не "array", а массив объектов T... приходися плодить всякие TCollection...

короче, Предусловия не могут быть усилены в подклассе.

могут

но для этого есть перегрузка методов

ты можешь для частных случаев делать отдельные методы

как это в той же java сделано

но этого нет в пхп

и в ближайшее время не будет

где же это усиление... это наоборот, ослабление ;)