От не певен, мені здається, що це проблема неврахування цього при роботі з базовим класом. Адже сам контракт імплементується на рівні мови, значить потенційно присутній всюди, незважаючи на неможливість його викликати

Бізнесові правила теж часто так звучать «та цього ніколи не станеться», але ж ми знаємо, що станеться

Класне пояснення, ніколи не дивився в такому розрізі

Вибачте, але не бачу сенсу продовжувати дискусію адже її нема

Ви праві, контракти нічого не варті, все придумали ще 40 років тому, LLM генерував не тільки коментарі, а і всю статтю

Наскільки я знаю Eiffel і Ada створювались для критичних систем (авіація, медицина), де коректність важливіша за швидкість розробки. Більшість бізнес-додатків живуть в іншій реальності.

Замість повноцінних контрактів мови пішли шляхом часткових рішень, які покривають 80% потреб:
Статична типізація (TypeScript, Kotlin, Swift)
Nullability annotations (C#, Kotlin)
Runtime assertions та property-based testing
Лінтери та статичні аналізатори

Так, зміна вимог справді бʼє по контрактах. Але контракти саме для того і існують, щоб зробити такі зміни явними і контрольованими. Питання в тому, чи потрібна вам така строгість.

То ж, як на мене, висновки занадто категоричні. Контракти не прижилися не через «проблеми ООП», а тому що індустрія знайшла більш прагматичний баланс між строгістю і швидкістю (чи продуктивністю)

Просто цікаво, на вашу думку, а які прийшли проблеми з там, що прийшов SOLID і намагання рухати PHP в сторону справжньої ООП, чи чим вона не справжня?

Так, дякую, дійсно важливе зауваження

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

з

OutOfMemory

не згоден, адже це розповсюджено і на клас і на підклас, вони ж закладеня на значно більш базовому рівні і є загальними

Згоден по всім пунктам, дякую за якісне доповнення