Это прекрасно, повторю.)
Видите мы зашли в тупик. Так что давайте не будем кидаться такими ничего незначащими кроме нашего отношения фразами и попробуем выделить суть.
Если я правильно понимаю, вы упираете на то, что минус DSL в том что его нужно учить. Претензия к пайпу туда же. И Собственно вы правы, нужно. Но для этого есть документация.
Озвученный минус про контекст я отвергаю, так как он просто не нужен для правила валидации.
> Вместо яркого, лаконичного и понятного кода на PHP
Вот не надо. Даже в какой нибудь небольшой форме есть не одно поле, на которое не одно правило валидации. И ваш код на чистом php не будет лаконичным. И будет он дублироваться темболее если форм много. И придется вам выносить эти функции куда то. и т.д.
И вы так и не сказали как мне в это дело поместить сообщение.
И в итоге сравнивая плюсы и минусы я очень рад что в Ларе сделали DSL именно на правила валидации.
Именно, это свой DSL и это прекрасно. Он короче и лучше читаем. Учить вам придется много чего если вы хотите писать на фреймворке.
И ваш пример очень рафинированный. Добавьте туда еще пару тройку правил на поле. И в вашем примере как мне задать сообщение об ошибке? А мультиязычное сообщение об ошибке? А Лара имеет конвенцию привязанную к имени правила валидации.
А как связано то, что модель содержит метод сериализации и то что — «это слой данных, который не должен ничего знать о том, в каком формате он будет представлен для пользователя»? Наличие базового метода сериализации в объекте это же нормальное явление.
Тем более забавно как вы подтверждаете свою точку зрения опираясь на статью (> «По мне, так данная статья еще раз это подтверждает.») корень проблемы которой в ином. Хитро)
Хватит пихать сою «крайне спорную» статью везде. А проблема преобразования сырых данных в объекты (hydration) так то будет в любом случае. В случае с Ларой накладные расходы конечно очень велики. Но возьмите и сделайте именно тут выборку без гидрации, не? (https://gist.github.com/anonymous/c3d7d713722f3559b922fd638454d03a)
Понятно же что, есть случаи когда нужна простота и удобство кода и скорость разработки, а есть случаи когда нужна производительность.
Ну как бы стайлгайд од какого то чувака это не доказательство и не правило хорошего тона. В разных фирмах или сообществах свои стайлгайды. (напомню что я за snake_case, но не против camelCase)
тоже ближе snake_case однако не слышал что это «правила хорошего тона» и знаю много разработчиков которые любят camelCase и в названиях таблиц и в именах полей (и ругаются на Laravel что она по дефолту работает именно со snake_case).
Видите мы зашли в тупик. Так что давайте не будем кидаться такими ничего незначащими кроме нашего отношения фразами и попробуем выделить суть.
Если я правильно понимаю, вы упираете на то, что минус DSL в том что его нужно учить. Претензия к пайпу туда же. И Собственно вы правы, нужно. Но для этого есть документация.
Озвученный минус про контекст я отвергаю, так как он просто не нужен для правила валидации.
> Вместо яркого, лаконичного и понятного кода на PHP
Вот не надо. Даже в какой нибудь небольшой форме есть не одно поле, на которое не одно правило валидации. И ваш код на чистом php не будет лаконичным. И будет он дублироваться темболее если форм много. И придется вам выносить эти функции куда то. и т.д.
И вы так и не сказали как мне в это дело поместить сообщение.
И в итоге сравнивая плюсы и минусы я очень рад что в Ларе сделали DSL именно на правила валидации.
И ваш пример очень рафинированный. Добавьте туда еще пару тройку правил на поле. И в вашем примере как мне задать сообщение об ошибке? А мультиязычное сообщение об ошибке? А Лара имеет конвенцию привязанную к имени правила валидации.
Тем более забавно как вы подтверждаете свою точку зрения опираясь на статью (> «По мне, так данная статья еще раз это подтверждает.») корень проблемы которой в ином. Хитро)
Понятно же что, есть случаи когда нужна простота и удобство кода и скорость разработки, а есть случаи когда нужна производительность.