Почему сигнатуру конструктора можно переопределять? Для чего эта условность?

В смысле, не складно

class Car
{
  public function engineStart(string $key)
  {
    $this->engine->start();
  }
}
class Bmw extends Car
{
  public function engineStart(Key $key) // @throws LiskovSubstitutionException...
  {
    $this->engine->start();
  }
}

Григорий Васильков,

В смысле, не складно

Что не складно?

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

Григорий Васильков,

Собственно про это я задал вопрос - почему конструктор в данном случае особенный

Родитель не может знать что может понадобится для создания экземпляра наследника

Родитель может зафиксировать интерфейс, и это логично. Можно обращаться с объектом базового класса при этом не зная каким конкретно из наследуемых классов он является. Но конструктор не является частью интерфейса. И создавать объект можно только конкретного класса. И ограничивать способ его создания нельзя, т.к. нельзя никак предсказать что может понадобится для его создания.

Стало быть конструктор нельзя использовать для передачи аргументов?
То есть конструктор должен наполняться инжектором зависимостей, и потому предсказать требуемое "невозможно" (требуемое определяется его реализацией. интерфейсом - нет)

Если в конструктор кидаются строки и цифры (new Obj('hello', 'world')), как я учил это, пошагово когда-то, то это есть неправильно или где. Стало быть когда делают паттерн ValueObject чтобы проверить и гарантировать значение вместо словаря из значений - то скорее это единственное исключение, когда конструктор должен принимать аргументы и создаваться через new.

Григорий Васильков,

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

У конструктора есть только 1 применение: создать объект. Не очень понял о чем речь идет дальше

green_goo, извиняюсь

new Object('hello', 'world') - здесь на вход передаются типизированные аргументы - строки
new Object(HelloService $service, WorldService $service) - здесь на вход подаются зависимости, без которых он не может выполнить то, как его реализовали

если у нас есть обьект, например Эксепшен, который стандартный и задокументированный - то большинство разработчиков ПХП привыкло, что первый параметр - это строка, второй параметр - это код, третий это \Throwable $previous.

Если наследовать эксепшен - он по прежнему должен уметь делать getMessage(), getCode() и getPrevious().

Однако когда я задаю вопрос - почему эксепшен такой узкофункциональный в дефолтной реализации в пхп (наверняка есть причина), в ответ приводят что я высасываю из пальца проблемы, дескать просто возьми измени конструктор, и запихай туда ErrorBag. Или даже Response. Или что угодно. И потом ты хотел бы getMessage() а тебе в ответ захардкоженный эксепшен - дескать "у нас тут особенный эксепшен, он плевал на стандарты и умеет делать только getMessages() : array.

Работать безусловно будет.

Но вот Барбара Лисков плачет кровавыми слезами, когда эксепшен благодаря возможности написать конструктор как тебе хочется - может делать что угодно, как угодно и в любой проекции. И ты читаешь потом

throw new \MySuperException(new Response(500), $data);

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

Но болт с маслом. Кто-то его переопределил, запихнул туда пол-программы, пыха не ругнулась и он уверен что он полностью правильно поступил и еще и обвиняет что проблема из пальца

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

Григорий Васильков, конструктор НЕ является частью интерфейса. Это способ создать конкретный объект, но не способ работы с этим объектом. Работа с объектом осуществляется через интерфейс, при этом вызывая метод можно не знать настоящий его класс. И чтобы это было возможно, необходимо чтобы аргументы были согласованы между. С конструктором такого никогда не будет.
Что действительно важно, так это всегда вызывать конструктор родителя в наследнике, что к сожалению php позволяет не делать. Был бы вызван конструктор в коде из вопроса, не было бы и дальнейших проблем. И в случае с кастомным классом исключения то же самое: конструктор может быть любым, но при условии что он вызовет конструктор родителя. И что действительно требуется от объекта исключения:

он по прежнему должен уметь делать getMessage(), getCode() и getPrevious()

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

green_goo, спасибо