Comments 32
'rules' => new Assert\Optional([
new Assert\Type(['type' => 'array']),
new Assert\All([
'constraints' => [
new Assert\Collection([
'week_days' => [
new Assert\Type(['type' => 'array']),
new Assert\Count([
'min' => 1,
'max' => 7,
]),
new Assert\All([
'constraints' => [
new Assert\Choice(['choices' => range(0, 6)]),
]
]),
],
'hours' => [
new Assert\Type(['type' => 'array']),
new Assert\Count([
'min' => 1,
'max' => 24,
]),
new Assert\All([
'constraints' => [
new Assert\Choice(['choices' => range(0, 23)]),
]
]),
],
'group_id' => new Assert\Optional(new Assert\Type(['type' => 'integer'])),
])
]
]),
]),
может быть представлено объектом класса правила или замыканием
Это называется по-русски «анонимная функция» или «лямбда-функция». Использование термина «Closure» в PHP — ошибка разработчиков, в которой они не раз уже каялись.
Closure — это замыкание контекста на Lambda. А никак не сама Lambda.
Во-первых, не замыкание контекста на анонимную функцию, а замыкание анонимной функции на контекст.
Во-вторых анонимные функции в php, хотя и не замыкаются на контекст исполнения, тем не менее могут сменить внутренний контекст (ссылку) $this в ручном режиме (Closure::bind(), $func->bindTo()), и быть в этом смысле замкнуты на переданный объект.
Таким образом, однозначно утверждать, являются ли анонимные функции в php замыканиями или нет — нельзя. И уж тем более сложно говорить о том, хорошо это или плохо. Это просто особенность языка и ее нужно знать. А Ваши выкрики в духе "ололо! Closure — не Clousre!", просто неуместны. Ибо статья о разработке на PHP написана разработчиком PHP для разработчиков PHP. И мы — разработчики PHP прекрасно понимаем, что значит замыкание в контексте PHP. Так что, в принципе, носом нас в это можно и не тыкать.
я планирую написать статью, где попытаюсь сравнить свою библиотеку с другими решениями
жду сравнения с этим — https://github.com/auraphp/Aura.Filter
$messages = ['attribute' => i18n('validation.attribute.not_empty')]
Я думаю, было бы отличным решением, дать пользователю возможность, самому определить методику перевода.
Например так (псевдокод):
$validator = $serviceLocator->get('validator');
$translator = $serviceLocator->get('lang');
$validatror->setTranlator(function($phrase) use ($translator){
return $translator->translate(phrase);
});
1) Это всего лишь возможность. Никто не заставляет ей пользоваться.
2) Это декларативно. Единожды объявил переводчик, и забыл.
3) Это позволит не городить "беготню" по массивам самому.
4) Это ооп в конце-то концов.
И я действительно не понимаю, какую проблему может доставить делегирование дополнительного функционала любому объекту на Ваш выбор.
1) время
2) поддержка
Которые могут стать не такими обременительными, если стать контрибьютером и дополнить код на гитхабе. Но опять таки — зачем? ведь есть же другие либы где все это уже есть…
И опять же, каков смысл еще одной библиотеки если есть другие? Какие отличия?
сейчас на работе идёт процесс рефакторинга, и я хочу в итоге внедрить эту библиотеку.
Вот этого делать не стоит. Так как у вас нет веских причин
Мне такой подход показался не очень удобным и я решил попробовать создать альтернативу
Тоже так себе аргумент. достаточно было бы написать обертку как вам нравится. Но опять таки — зачем делать тоже самое, просто в другой оболочке без значительных изменений? Людям гораздо проще работать с вещами которые им уже знакомы, пусть и сделанные с неудобной архитектурой.
И еще у вас нет поддержки ICU в сообщениях
если не брать валидаторы от Laravel и Symfony
а почему их не брать? Оба валидатора хорошие и оба можно использовать как самостоятельные пакеты к любому проэкту. B обеих больше функционала, чем в вашем валидаторе и за обеими стоят изестные разработчики и комньюнити.
Это тип недостаток или что? Вместо того что бы писать свой валидатор проще сделать отдельный пакет, который добавляет fluent-интерфейс для построения правил и реюзает все возможности этих валидаторов.
Повторюсь — "реализовать другой способ задания правил" и "написать свой валидатор" это чуть разные задачи. Просто меня ситуация с валидаторами слегка удручает) Я пока использую symfony/serializer но мне приходится писать кастомные валидаторы что бы пофиксить баги и "неудобства" при использовании оного без форм.
Держите данные под контролем