а что там не понятного? я типизирую параметры и возвращаемое значение через накладываемые а них ограничения. что-то типа ассертов, только с поддержкой автоматического приведения типов и вынесенные в отдельные именованные сущности
А я проникся… Описать проверки и не всегда очевидные методы приведения типов, а потом это как откровение подать. А несогласных Вот только Вы для себя решите, тогда для чего исключения выбрасывать? И чем тогда это лучше, чем (int)$id или специфической для конкретного проекта набора фунций с таким же функционалом? или и тогда зачем приводить типы? По Вашей логике PHP: <?php return aBool($mysqli->affected_rows); ?> должно бросить исключение (впихнёте же туда is_bool(), верно?) А я хочу всего лишь PHP: <?php return (bool)$mysqli->affected_rows; ?>
Я за type hinting скалярных типов. Пусть даже строгий, но чтобы был, хотя, имхо, лучше мягкий. Даже где-то здесь с год назад писал, что подобное было бы прикольно.
да-да, там всего-лишь функции, условия, циклы... любой дурак может ими воспользоваться. но почему-то редко кто додумывается до их реюзинга и систематичного использования. он действительно идиот, раз принялся хаять даже не прочитав статью (а если бы он её прочитал, то не предлагал бы таких глупых "альтернатив"). чтобы помочь программисту обнаружить ошибку. если он посчитает нужным, чтобы к числу преобразовывалась даже строка "xyz", то он всегда может заменить aNumber на aSoftNumber, который не бросает исключений. гораздо большим числом возможных типов это оно и есть за тем, что некоторые типы совместимы между собой. и замена одного другим не является ушибкой. нет, исключение бросит aStrongBool, а aBool выполнит преобразование в соответствии с обычными правилами, но в дополнение у объектов проверит показания метода _toBool.
почему бы не назвать всё своими именами: «функции контроля типов» и не городить огород? Кстати, из-за необходимости всё равно плодить в коде try {} catch () реюзабельность постепенно стремится к нулю. И не про типы вы тут говорите, а всего лишь про форматы представления данных (согласен, не так амбициозно звучит) Типы у нас всё же можно эмулировать c помощью нэймспейсов а по приведённым примерам не скажешь… Так почему, всё же, и проверка и приведение в одном месте? В чём смысл? Чтобы не быть голословным потому что разделение этих двух, по сути соверщенно различных, действий плодит код? Что, каша лучше, чем копипастинг? Хм, странно PHP: <?php try{ Validate::radio($data['f_gender'], array('male', 'female'), _("Please select gender!"), 'err_gender'); Validate::date($data['f_month'], $data['f_day'], $data['f_year'], 'err_date'); Validate::name($data['f_fstname'], 'err_fstname'); Validate::name($data['f_lstname'], 'err_lstname'); Validate::password($data['f_password'], 'err_password'); Validate::email($data['f_usermail'], 'err_usermail'); } catch (CoreException $e) { // … } ?> А ни Psih, ни я из себя гениев не строим… Правда у нас по коду понятно что за данные и какой формат от них ожидается, а не безличные number, bool, string
это никак — думал совсем про другое, когда писал. облажался против того, что интерфейсы, если очень упрощённо, позволяют организовать пользовательский тип данных для объекта спорить не будем?
типа мы берем тот же валидатор и присабачиваем к нему интерфейс c приведением к нужному типу и ограничениями, а почему сразу не написать все это внутри или просто чтобы не трогать написанный класс, а потом дописывать нужный интерфейс в случае чего? т.е. как это на деле?
ну в той теме, на которую Luge дал ссылку - свои валидаторы определялись так: class myValidator extends baseValidator { ... } и потом создавалась инстанция myValidator и через нее добавлялись правила. Это в корне неверно, теперь будет BL_Validator::register(new myValidator()); Ну и много прочей ерунды, совсем другой код (к сожалению сложнее, но зато правильнее). Оно-то в принципе уже есть, но слабовато оттестчено +может я буду менять что-то.
а мне нравится термин тайпкастер. короткое, звучное, и отрожает суть. нет никакой особой необходимости. при нормальной работе скрипта никаких исключений не возникает. а чтобы нарисовать пользователю страницу с ошибкой в люом случае придётся использовать либо блок catch, либо блок else. ртфм http://ru.wikipedia.org/wiki/%D0%A2%D0% ... 1%8B%D1%85 то есть? ещё один не читал, но осуждает =_="
а) а зачем? никто не будет, оно просто не нужно б) модель бугага. А это точно нужно делать здесь? А что если я потом захочу поменять ф-цию хеша (пускай даже для новых пользователей)? если уж на то пошло - кто соль возвращать будет?
во-во, если я ожидаю что данные придут в конкретном формате, то любое отклонение это уже не нормальная ситуация. Тут мы как раз и возвращаемся к вопросы «почему в одном месте данные проверяются и изменяются, если это совершенно разные процессы» имхо, разговор зацикливается. Можете не отвечать, всё равно ничего кроме фанатичного «моя идея хороша, а вы все не поняли» пока ничего не было сказно
ну да, а «строка длиной 6 символов начинающаяся с подчёркивания, и содержащая только буквы в нижнем регистре» будет себя вести как-то иначе, чем любая другая строка и где здесь про то, что наложив какие-то ограничения на форму мы создаём некий новый тип данных?
А если не утрировать? и взять, например, телефонный номер? Любая другая строка нам как бы не подойдет А оно сильно взаимозаменяемо с номером кредитной/клубной карты?
А работа с этими строками из 12 и 9 символов будет чем-то существенно отличаться для твоего скрипта? Ограничения накладваются на формат записи и связано это не с тем что у нас кредитка или телефон, а всего лишь потому что в поле для телефона кредитку не запишешь.
Эм? т.е. если я попытаюсь совершить платеж с номером телефона вместо кредитки это так и надо? А в некоторых случаях это может еще даже и пройти и чего мне делать?
Пароль у нас хешируется базой, а имена к camel case приводить то нафиг? Это поля в базе и форме, какой camel case... Правильно сказано - валидация и фильтрация - это разные вещи. Данные по разному можно фильтровать в зависимости от того, что собственно они представляют. Я лично не очень люблю, когда всё слишком автоматизировано - всегда найдётся 30-40% случаев, когда это мешает и либо нужно расковыривать чёрный ящик, либо переходишь к низкоуровневым методам (а они как правило красиво не продуманы и выходит чёртова каша). Так что валидация валидацией, а фильтрация это уже другое. Не говоря уже о том, что не так уж редко данные приходят из формы, потом они полностью перелопачиваются и ложатся в базу совсем в другой структуре - в этом случае фильтрация и нормализация может только повредить. См. пример ниже. Пример из реальной задачи: В системе есть номер телефона. Есть международный формат (6390хххххх) и локальный (090хххххх). Есть системы, которые принимают номер либо в обоих форматах, либо исключительно в международном, либо исключительно в локальном. Соотвественно и пользователи их пишут по разному. Тут совмещать валидатор и нормализатор - глупая затея. Поетому сперва валидируем все данные, а потом мы их уже нормализуем если надо.
Бгг. Сдается мне что ты таки не понимаешь. Фокус в том что 12/05/2001 у тебя на экране это и строка и дата и вот это 1007503200 дата (в другом формате) и строка Но ты, конечно, можешь сколько угодно тешить себя иллюзией, что это все байты, просто в разном формате