Приведение к типам в Yii::app()->request

А как же float? А отрицательные значения?

Вся правда об XSS или Почему межсайтовое выполнение сценариев не является уязвимостью?

Если украден пароль от ftp или, тем более, от ssh — какой смысл уже делать фильтрацию данных из базы? Вам с полным успехом запишут эксплойт прямо в код. Тут чистое везение, что был доступ только в uploads. Однажды такое произошло на одном из сайтов украинского вуза. Код просто был удалён, на его место положен вирусный код. Бекапов рабочего сайта, конечно же, у людей не оказалось — полгода работы и много денег пропало.
А то, каким образом украден пароль — так это 99% троян, при чём заливка php-скрипта чаще всего тоже выполняется ботами.

AMatch — проверка входных параметров в PHP

По-поводу размещения условий «справа налево» — это особенность реализации. Увы, первый параметр более важный: ->key(42) означает «ключ существует и его значение равно 42». Если первым параметром принимать условие: ->key('array') — то уже не получится сделать короткие записи. Так что да, Йода-код, но позволяет значительно сократить текст.

AMatch — проверка входных параметров в PHP

> гораздо больше свободы в формировании логики валидации, нежели «from_topic(specialValidation(), true)»

Я тут подумал ещё насчёт этой фразы. Все-таки, использование замыканий удобнее в виде отдельной возможности, а ->key(true, true) или key->(false, false) может пригодиться само по себе, т.к. позволяет применить в валидации сторонний код, не адаптированный под этот стиль. Например, ->get_profile(is_admin(), true) — по сути, вызов глобальной функции is_admin() в данном случае либо разрешит, либо запретит получение профиля пользователя в зависимости от типа авторизации.

AMatch — проверка входных параметров в PHP

Благодарю, посмотрю.

AMatch — проверка входных параметров в PHP

Конечно не избавит. Но облегчит, т.к. сам AMatch уже тестами покрыт. Если развить идею и всё-таки вынести обработчики сопоставлений в отдельный класс и регистрировать их каким-то удобным быстрым способом — несколько стандартных протестированных классов сильно упростят жизнь. Думаю сделать все-таки возврат кодов ошибок вместо текста для упрощения локализаций. Тогда пишется маппинг, подгружаются свои тексты, один раз тестируются — и в остальных случаях в тестах достаточно будет проверить через dataProvider граничные значения сразу скопом. Это удобно.

AMatch — проверка входных параметров в PHP

Пример несколько лишен смысла, конечно же. Т.к. цель — показать разные возможности, а не решить практическую задачу.

Использование аннотаций в PHP 5.4 для АОП и не только

Честно говоря, немного запутался, когда увидел «Around». Вызов аннотатора «около» функции. Всё-таки это замена, наверное лучше что-то вроде instead использовать. Вообще, интересная штука. Можно примеры практического использования? Событийную модель на основе такого неплохо реализовывать, но не мешает ли код, например, юнит-тестам?

Использование аннотаций в PHP 5.4 для АОП и не только

if (isset(self::$cache[$options[0]])) — лучше array_key_exists. Метод может вернуть null, который игнорит isset.

AMatch — проверка входных параметров в PHP

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

AMatch — проверка входных параметров в PHP

Zend_Validate не использовал. Посмотрел сейчас примеры — всё-таки несколько другая основная идея там. В AMatch ключевая цель — ускорить написание типовых проверки, сократить запись для удобства восприятия. В случае Zend_Validate для реализации описанных примеров понадобится целое полотно кода на каждый параметр. Там как раз целевое назначиние — возможность написания различных «модулей» валидации с общим стилем.
По-поводу:
> использовать замыкания вместо call_user_func
— это вполне годная идея, и я не против её реализации. Но тут нужно сначала продумать возможные варианты. Я сначала для себя пишу пример желаемого использования, потом думаю — как его удобно можно сделать. Напишите, как вы видите синтаксически использование замыканий для внешних модулей?

AMatch — проверка входных параметров в PHP

Я про пространство имён самих входящих ключей. Например AMatch::run()->stop() нельзя сделать, т.к. имя «stop» может быть ключём валидируемого массива.
Вынести проверки во внешние классы — это возможное направление развития. Но всё-таки каждый такой новый шаг всё более и более усугубляет скорость и использование памяти. Мне тут больше нравится принцип callback для ситуаций, которые не попадают в типовые. А если типовых калбеков становится больше чем нужно — вносить их в основной код.

AMatch — проверка входных параметров в PHP

Я бы с удовольствием избавился от stopMatch или, хотя бы, привёл их к коротким формам. Но резервировать горячие имена в общем пространстве — неблагодарное дело. Приходится терпеть лишние буквы :)

AMatch — проверка входных параметров в PHP

Спасибо. Было бы неплохо услышать отзыв про опытную эксплуатацию.

AMatch — проверка входных параметров в PHP

Хотя мне нужно на вход так или иначе принять массив и флаги. AMatch::doc_id('', '!array', $params, $flags) — пожалуй не лучший подход. Всё-таки метод-конструктор тут более нагляден.

AMatch — проверка входных параметров в PHP

Мне нравится у вас использование __callStatic(). Это избавляет от начинания с runMatch(). Возможно, применю у себя такой подход.

AMatch — проверка входных параметров в PHP

В рамках статьи $_REQUEST означает — любые данные извне. Это не стоит внимания.

AMatch — проверка входных параметров в PHP

$_GET/$_POST etc. А что?