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

у тебя был общий тип - стринг

и какая-то реализация (подтип) вдруг решили принимать не любой стринг а какой-то свой

на интерфейс это никак не влияет

но LSP ломается ровно так же как и в твоем примере с json

p.s. изменения о которых ты говорил нужны были что бы закрыть BC break в 7.2

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

так, ну ты и раньше мог просто так запихнуть что угодно

мы не говорим о том что код бывает н валидный

и наследование топлива карантирует совместимость со всеми двс

любой паттерн можно испаганить

я еще раз повторю - и без этой фичи LSP ломается так же как и с этой фичей

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

и клиентский код что раньше мог запихнуть не строку а бул, что сейчас

удачи

потому что эта фича не панацея

потому что эта фича не панацея

ммм

это кастыль

IDE автокомплит!

и это никто не отрицает)

дополнительная проверк

чтобы раньше времени посдать

в данном случае это не расширение контракта а отмена контракта

ты серьёзно против сеттеров и за отмены контрактов?

ты серьёзно против сеттеров и за отмены контрактов?

я за то что бы люди думали

и никто контракты не отменял

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

о чем вообще речь

ооп можно строить и на массивах с процедурщиной

ооп можно строить и на массивах с процедурщиной

нет, это будет не ооп

только условно

а хотя...

ну короч мы возвращаемся к тому "что такое ооп"

отсутствие сахара по сути

если в кратце я прифигел от такой вольности

не нравится теб контракт - сделай новый метод

ты серьёзно против сеттеров и за отмены контрактов?

по поводу сеттеров: - я не против сеттеров, я сам их использую. Там где, как ты метко подметил, "мне пофиг". а там где не пофиг я стараюсь их не юзать просто потому что они могут скрыть от меня важную инфу. - в большинстве случаев сеттерам есть альтернативы. И я часто вижу проблемы в духе "лепим все в одну табличку просто потому что а зачем по другому?" - сеттеры - простой способ упустить извиду проблемы со связанностью и декомпозицией. по поводу контрактов: - ты не можешь описать контракты типами, что бы в компайлтайм. - ты можешь попробовать описать контракты через AOP но в случае с php это кастыли - изменения в php 7.2 разрешают тебе расширять прекондишены контрактов что полезно. В 7.3 ВОЗМОЖНО разрешат делать это корректно, с учетом ковариантности/контрвариантности (то есть и для ретурнов можно будет). - с точки зрения LSP и с точки зрения выстрелов в ногу ничего не поменялось

не нравится теб контракт - сделай новый метод

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

я уже не помню что именно они так фиксили

по поводу сеттеров: - я не против сеттеров, я сам их использую. Там где, как ты метко подметил, "мне пофиг". а там где не пофиг я стараюсь их не юзать просто потому что они могут скрыть от меня важную инфу. - в большинстве случаев сеттерам есть альтернативы. И я часто вижу проблемы в духе "лепим все в одну табличку просто потому что а зачем по другому?" - сеттеры - простой способ упустить извиду проблемы со связанностью и декомпозицией. по поводу контрактов: - ты не можешь описать контракты типами, что бы в компайлтайм. - ты можешь попробовать описать контракты через AOP но в случае с php это кастыли - изменения в php 7.2 разрешают тебе расширять прекондишены контрактов что полезно. В 7.3 ВОЗМОЖНО разрешат делать это корректно, с учетом ковариантности/контрвариантности (то есть и для ретурнов можно будет). - с точки зрения LSP и с точки зрения выстрелов в ногу ничего не поменялось

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

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

в духе, я привел один из примеров

я вообще загоняюсь по связанности, для меня это главное

каплинг и кохижен

по поводу сеттеров: - я не против сеттеров, я сам их использую. Там где, как ты метко подметил, "мне пофиг". а там где не пофиг я стараюсь их не юзать просто потому что они могут скрыть от меня важную инфу. - в большинстве случаев сеттерам есть альтернативы. И я часто вижу проблемы в духе "лепим все в одну табличку просто потому что а зачем по другому?" - сеттеры - простой способ упустить извиду проблемы со связанностью и декомпозицией. по поводу контрактов: - ты не можешь описать контракты типами, что бы в компайлтайм. - ты можешь попробовать описать контракты через AOP но в случае с php это кастыли - изменения в php 7.2 разрешают тебе расширять прекондишены контрактов что полезно. В 7.3 ВОЗМОЖНО разрешат делать это корректно, с учетом ковариантности/контрвариантности (то есть и для ретурнов можно будет). - с точки зрения LSP и с точки зрения выстрелов в ногу ничего не поменялось

- сеттеры - простой способ упустить извиду проблемы со связанностью и декомпозицией. они и нужны там гже нет связанности

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

- сеттеры - простой способ упустить извиду проблемы со связанностью и декомпозицией. они и нужны там гже нет связанности

но большинство их лепит просто так) не думая0

как ты там говорил - проще запретить

по поводу сеттеров: - я не против сеттеров, я сам их использую. Там где, как ты метко подметил, "мне пофиг". а там где не пофиг я стараюсь их не юзать просто потому что они могут скрыть от меня важную инфу. - в большинстве случаев сеттерам есть альтернативы. И я часто вижу проблемы в духе "лепим все в одну табличку просто потому что а зачем по другому?" - сеттеры - простой способ упустить извиду проблемы со связанностью и декомпозицией. по поводу контрактов: - ты не можешь описать контракты типами, что бы в компайлтайм. - ты можешь попробовать описать контракты через AOP но в случае с php это кастыли - изменения в php 7.2 разрешают тебе расширять прекондишены контрактов что полезно. В 7.3 ВОЗМОЖНО разрешат делать это корректно, с учетом ковариантности/контрвариантности (то есть и для ретурнов можно будет). - с точки зрения LSP и с точки зрения выстрелов в ногу ничего не поменялось

- изменения в php 7.2 разрешают тебе расширять прекондишены контрактов что полезно. не расширить, а полностью изменить. оно может быть только 1 в этом и проблема. для новых мест с новым вызовом и новыми аргументами - нужна новая функция

- изменения в php 7.2 разрешают тебе расширять прекондишены контрактов что полезно. не расширить, а полностью изменить. оно может быть только 1 в этом и проблема. для новых мест с новым вызовом и новыми аргументами - нужна новая функция

"убрать тип" = расширить, а не полностью изменить

я так не думаю

дальше это на твоей совести

расширить это подолнить

а не снять ограничение

ой все

ххотя да игра слов

php вообще ужасный язык

на этом и закончим

лсп как раз про РАСШИРЕНИЕ

если это метод заправить авто а в авто заинъектили депенденси двс на 95 не стоит методом "заправить" заливать незамерзайку

если у авто 2 заправки электро и топливо это разные методы с разным БЛ

если речь про php

так все ваши проблемы из-за пхп?

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

Идентификационный код не меняется Серия, номер, дата и место выдачи меняется Меняется паспорт на основании какого-то промеж документо, вроде разрешения на смену имени Этот документ и подтверждает в дальнейшем твои старые анкетные данные. Т.е. работает как связывающая сущность Если вы об этом

ERROR: S client not available

так все ваши проблемы из-за пхп?

в чистом js те же проблемы )

php хороший

пока живой)

по русски не понимаю, читаю только на английском

ну, тогда можна попробовать - https://translate.google.com

ну, тогда можна попробовать - https://translate.google.com

мне нужен оригинал, только нормальный, желательно с навигацией по главам и т.д., старая книга а до сих пор нет нормального скана.

https://www.csie.ntu.edu.tw/~r95004/Refactoring_improving_the_design_of_existing_code.pdf

хз, первая ссылка в гугле

я в бумажном виде просто купил

~$50 за epub версию

не думаю что это дорого

https://www.csie.ntu.edu.tw/~r95004/Refactoring_improving_the_design_of_existing_code.pdf

вот как раз эту и читаю сейчас

в чистом js те же проблемы )

чистый это флоу?

нет js кроме ECMA-262

нет js кроме ECMA-262

ну вообще нет js... есть ecma.... js это как "ксерокс" вместо "копировальной машины"

ну и как бы, есть ECMAScript 2017, актуальная версия, и не ипет

ну вообще нет js... есть ecma.... js это как "ксерокс" вместо "копировальной машины"

это вообще-то отсылка была

ну и как бы, есть ECMAScript 2017, актуальная версия, и не ипет

понаштампуют форков по обхявлениям

понаштампуют форков по обхявлениям

ты уже разобрался с LSP?

о а тут был тредик по 7.2 и LSP ? а то я пытался объяснить в соседнем чатике

к чему вы пришли, ослабление пред* условий, хорошо ?

ты уже разобрался с LSP?

language server protocol?

к чему вы пришли, ослабление пред* условий, хорошо ?

ослабление пред условий ни хорошо ни плохо - оно разрешено в рамках LSP. А товаристч не понимает разницу между интерфейсом и контрактом судя по дискуссии

к чему вы пришли, ослабление пред* условий, хорошо ?

пред условий же, нет?

пост условия это ретурн тайп

или его тоже можно опускать?

а я и потер сначала, потому что сам засомневался)