Пользовательские типы в PHP

Хотя я бы просто использовал json schema и библиотеки их валидации.

Если это правило будет применяться впоследствии, то его в любом случае придётся выносить отдельно. Ещё какая-то переработка потребуется, когда правила нужно будет комбинировать.

Когда нужно — тогда и будет. Я о том и говорю, что декларативный подход следует комбинировать с императивным. Что-то вроде

class User
{
    public function __construnct(string $name, array $addresses)
    {
        Assertion::regex($name, '/.../', sprintf('Username is not valid: %s', $name));
        $this->addresses = new AddressCollection($addresses);
        $this->checkNameForCorrectAddress($name, $addresses);
        $this->name = $name;
    }

    private function checkNameForCorrectAddress(string $name, AddressCollection $addresses)
    {
         if ($addresses->hasAddress('Иваново') && $name !== 'Иванов') {
             throw new InvalidArgumentException("В Иваново могут проживать только Ивановы");
         }
    }
}

А вообще всё так и работает) Тип — это объект, который реализует метод TypeInterface::validate. Наследование от AbstractType ещё и делает его callable, что позволяет передать его, допустим, в array_filter.

Тип у вас — объект описывающий правила валидации иерархически вложенные друг в друга, правильно? С помощью ваших "типов" вы можете сказать — вот этот массив — он вообще совпадает с описанием структуры или нет. О том, что вам каждый раз, когда нужно проверить соответствие типу — придется проходить по всему массиву я уж молчу.

Я же говорил о том, что типы в ПХП уже есть — это классы. Между классом и вашим "типом" есть одна огромная разница — создание объектов, которые могут проверять валидность создания себя, а по-этому не должны быть в "невалидном" состоянии. Раз создали объект — значит он в валидном состоянии. А уж о тайпхинтенге и проверке instanceof я уж и молчу.

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

В случае с реализацией в форме обычного кода есть возможность полагаться на IDE, которая подскажет и названия типов, и их сигнатуры. Кроме того, описание чего-то вроде

Ну, есть валидатор описания структуры, который скажет что "неизвестный тип данных strrrng", или можно писать типа 'data' => type::string. '|'. type::int. Не говоря уже о том, что 'data' => 'string|object' вообще быть не должно, это такой большой подводный камень. А так — гляньте ту же JSON Schema спецификацию.

а можно ли рассматривать в качестве DTO объект с геттерами и сеттерами, необходимыми при отсутствии типизированных свойств в PHP? Это же фактически поведение)

Нет. Геттеры и сеттеры это методы доступа к данным. Для этого есть термин — анемичная модель.

Например, в роли DTO можно рассматривать сам пришедший объект данных без всяких трансформаций — JSON-объект совершенно точно не имеет поведения)

JSON — объект только в js. В php же это просто строка, которую он может декодировать в массив или stdClass. Некоторые рассматривают массив как DTO, но это не правильно. Главное отличие DTO, от массива в том что объект имеет явный список свойств и он типизированныей, что позволяет идентифицировать данные.

Валидация — это действие, совершаемое над данными, и она может происходить в том числе в отношении их типа.

Я разве говорил что не надо проверять данные на соответсвие типа? Я говорил что правила:

• Значение является строкой
• Строка длинною 2 симвоал

Это два отдельных правила, а не одно. А вот правило:

• Значение является кодом страны

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

field('code', country_code())

Но я попробую привести пример — INT(11). 11 — это длина строкового представления числа, которое занимает 4 байта.

Это пример из баз данных которые делались как универсальный сервис хранения данных. В приложении можно создавать свои типы и поэтому такие универсальные типы не нужны. Например:

• Phone — в БД будет INT(11) для Российского региона.
  (int не самый лучший способ хранения телефона)
• СountryCode — в БД будет CHAR(2)
• ArticleId — в БД будет INT или CAR(36) если это UUID

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

Всё верно. Вы создали валидатор и пользоваться им нужно как валидатором. Как я и говорил ранее, правила можно комбинировать. Условно:

field('age', [int(), min(2), max(5)])

field('name', [string(), length(128)])

field('titles', [lot(), size(5)])

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

field('id', [object(), instanceof(ArticleId::class)])

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