что то вы тут такое непонятное развели, что читать уже трудно )) по-моему всё просто: setId(int $id) setId($id) а вы скоро начнете приходить к: setId(notString $id) и прочей херне...
чтобы не требовалось, например, везде использовать сравнение не чувствительное к регистру, которое и медленней и неудобней. а что модель? предлагаешь нормализовывать в ней, а валидировать во вне? а почему бы и нет? меняй сколько влезет да кто угодно. запиши её в константу, например.
Это хорошо, но бывает и плохо. Ибо иногда лучше не догадаться, чем догадаться плохо. пример с датами тут более чем показателен. 12/10/2001 и 10/12/2001 и geoip в частном случае не поможет.
конечно. её можно будет передать в один набор функций и нельзя будет в другой. там всё есть. читай и просвещайся
а до базы он гуляет по программе в открытом виде? надёжней будет его маскировать сразу при получении. 1. грамотно 2. оно ещё и пробелы нормализует 3. чувствительные к регистру алгоритмы сравнения быстрее в том-то и дело. что нам не важно что они себя представляют. важно - что мы хотим получить. $phone= aMegaPhone( '090хххххх' ); // 6390хххххх $phoneForLocal= aLocalPhone( $phone ); // 090хххххх $phone= aMegaPhone( '6390хххххх' ); // 6390хххххх $phoneForLocal= aLocalPhone( $phone ); // 090хххххх я не вижу тут никаких проблем. оба типа замечательно конвертируются друг в друга, когда нам это необходимо.
как хочешь так и делай: можешь в ней а можешь во вне (тонкие/толстые модели) уу, капец. А если я 5 пользователей добавляю - пять констант делаем? все, я устал от этого неадекватства, отписываюсь от темы
и валидация и приведение - это контроль типов. зачем их разделять? зачем тебе соль для каждого пользователя?
Psih, я в целом на твоей стороне, но не все твои аргументы кажутся полностью обоснованными. Например: Это что теперь, GET не проверять и не приводить? Если я впишу в адресе "24fuck", то сценарий на сервере должен падать с фатальной ошибкой?
vasa_c Ну возможно этот вариант притянут за уши, да. Вообще после вот этого: http://habrahabr.ru/blogs/php/101229/ и соответственно оригинала: http://schlueters.de/blog/archives/139- ... trunk.html В internals поднялся такой хай, что комитерам патча щас должно быть жутко стыдно, т.к. их ранесли буквально в пух и прах. 99% что патч откатят в ближайшее время. Zeev Suraski отпостил следующий e-mail Судя по тому, что пишут, будет либо 1-й, либо 3-й вариант. Zeev'a поддерживают активно, в том числе и я. Лучший вариант, ИМХО, 1-й Будут новости с фронта, буду сообщать
Koc Не, не, это старая дока. Вот более новая, версия 0.5: http://wiki.php.net/rfc/typecheckingstrictandweak А вообще вот список всего, что относится к type hinting: http://wiki.php.net/rfc/typechecking
блин что то я вообще нифига не пойму. Будет автоприводиться или проверяться? Если проверяться, то нахрен оно надо, да еще и с какими то выбросами ошибок или нотисов или чего там?
Костян На данный момент не ясно, но судя по всему строгий тайпхинтинг просто не пройдёт, т.к. противников слишком много. Либо не будет вообще пока тайпхинтов, либо они будут с приведением типов. Пока ситуация видится именно так. Насчёт ошибок - думают ввести новый тип ошибок E_TYPE, который не будет включён в E_ALL. Генерироваться будет тогда, когда прозрачное приведение типов не возможно , по сути это будет аналог Warning'a: PHP: <?php function test(int $x) {} test(1); test("1"); test("abcd"); // E_TYPE warning
ааа, понятно. кстати мне не нравится варианты с ошибками вообще. Пользовательские да, но не базовые типы - пых же динамический, пусть приводит своими стандартными правилами без всяких генераций. Или хотя бы это бы регулировалось настройкой - генерить ошибку или насильно приводить по обычному.
Костян Ну тогда смысла от тайпхинтов нету вообще. Идея в том, что бы конвертировать без генерации ошибок когда один в другой тип конвертируется без всяких проблем. Но, как только у нас появляется что-то вида 5.243 => 5 - мы всё же конвертируем и делаем ошибку. Зачем? Потому что иногда бывают логические ошибки, когда скажем вместо if ($var === false) ставят if ($var == false) и получают дырку в скрипте. Тайпхинты не только позволяют такие места принудительно приводить, но и давать об этом знать разработчику с помощью error log - ибо это потенциальный баг и дырка в системе. Именно для этого ошибки и нужны.
и часто ты пишешь if($var==false) ? сродни: и часто ты забываешь эскейпить данные в БД? ищем иголки в стоге сена вот это правильно,потому что это уже структура упрощения языка, как дополнительная фича, только в данном случае я за FatalError потому что раз уж я хочу инт, тут уж никуда.
лучше бы блядь делом занялись, а не делали из пхп фиг пойми что в очередной раз. например требование структур в параметрах функции, а не только objects types, и кастинг к структурам, а то блядь на ошибку аля "must be string, string was given" звучит минимум идиотически. мнго косяков более интересных, чем приведение типов, мозг ломать второй раз - перенастраиваясь на новый хинтинг - никому не надо, а вот ЛОГИЧНОЕ поведение - НАДО. а магия очередная от разработчиков пхп имхо в пизду и поглубже, хватит ее уже имхо