Типизация и PHP

[@SamDark]

interface MyType {}

class MyClass implements MyType {
}

class NotMyClass {}

function do_something(MyType $class){
}

do_something(new MyClass());

[@stanis]

Да, классное решение. Но не для простых типов.

[@stanis]

Прошу прощения, это был ответ предыдущему оратору.

habrahabr.ru/blogs/php/40935/#comment_995488

[@ashofthedream]

Все таки использование switch в функции type, которая по сути для каждого типа выполняет свои действия — немножко неукладывается в объектно ориентированную парадигму. Посмотрите как сделаны валидаторы в ZF.

[@olen]

По-моему, для подобных утилитных классов лучше все-таки обойтись свитчем, а не создавать иерархию классов.
Если мы имели дело с какой-то концептуальной моделью, которая с высокой вероятностью будет меняться в процессе разработки, то да. А тут просто заранее известный набор типов.

[@ashofthedream]

И через некоторое время понять, что функция type выросла на 120 строчек и в нее добавился еще с десяток типов. Сегодня проверяем email-ы и title, завтра нам придется проверять еще даты и некоторые данные довольно сложными регулярками. И захочется иметь этот функционал в каком-то одном месте, а не раскиданом по всему проекту.

[@prn]

Реализация Zend_Validate удобна, но при большом кол-ве различных проверок больно сильно тормозит из-за большого кол-ва автоматически подгружаемых классов. особенно когда используется в связке с Zend_Translate

[@Morfi]

try {
…
} catch (Exception $e) {
throw new Exception($e->getMessage());
return false;
}

Что то я не понял )

[@Mekras]

Насколько я понимаю, здесь мы ловим исключение, сгенерированное одним из валидаторов (которые не знают логического смысла проверяемого значения) и генерируем исключение с уже более информативным сообщением. Это просто упрощённый пример.

[@Morfi]

имхо, бред, мы ловим исключение, создаем точно такое же с таким же сообщением и опять его выбрасываем, зачем его тогда ловить? ну или хотя бы, выбрасывать так throw $e.

[@Mekras]

Ну включите же фантазию! Это же пример. Сходу видно как минимум два варианта:

} catch (Exception $e) {
throw new MyCoolClassException($e->getMessage());
return false;
}

и

} catch (Exception $e) {
throw new Exception('Упс! Нельзя добавить новую сепульку, потому что: '.$e->getMessage());
return false;
}

[@ashofthedream]

А как это может помочь нам в реальной ситуации. Какой смысл, Что мы получив кроме усложения понимания кода и повышенного аппетита к ресурсам?

[@Mekras]

Это не ко мне, это к автору. Я лишь пояснил непонятный Morfi кусок кода.

[@freehome]

Тоже постоянно сталкиваюсь с подобной проблемой и посему уже много лет использую один раз выработанное правило — именовать переменные в соответствии с их типами (по первой букве).
Например: $bValidNumber, $iDigit, $sFileName, $oDbInstance и так далее.
Аналогичное правило распространяется и на имена классов/объектов.

Как неоднократно показала практика, внедрение подобного best practice в компаниях существенно облегчает понимание кода много месяцев спустя.
Да и имена становятся более приятными для чтения (вместо $var1, $str, $abc, etc).

[@Mekras]

Это называется «венгерская нотация», если не ошибаюсь. Только Вы тут смешиваете две разные и независимые друг от друга вещи.
1. Указание типа переменных
2. Значимые имена переменных.

Если убрать префиксы типов, то имена по-прежнему будут «более приятными для чтения (вместо $var1, $str, $abc, etc).»

P. S. Хочу заметить, что я не против венгерской нотации как таковой, я просто указываю на логическую ошибку.

[@ashofthedream]

Работал в компании, где применялась эта best practice. Недолго она применялась. Потому как для переменных классов есть PHPDoc, в котором мы можем указать нужный нам тип и IDE его спокойно может подхватить (про блокнотных девелоперов молчу). А все остальные нужно просто нормально уметь именовать. Об этом еще Макконнелл говорил в Совершенном коде. Расписав что и как там на целую главу.

А смысла добавлять s к переменной filename, которая по названию нам говорит что это строка я не вижу? Да и мое любимое — iId, имхо выглядит как полнейший маразм.

[@wayly]

Увы и ах, но пришлось отказаться от подобного наименования, ибо в PHP оно неэффективно.
Нередко встречаются случаи, когда изначально не знаешь, какой тип у тебя будет храниться в текущей переменной — это факт.

В качестве примера можно привести метод, принимающий переменную $array. Дальше он смотрит — если это массив — возвращает его и делов. Если строка — return explode(', ', $array);

Вот тут непонятки страшнее преимуществ, которые достигаются подобным именованием.

ЗЫ: это простейший случай ;)

[@gro]

Может быть вместо всех этих мучений перейти на жёсткотипизированный язык?

[@LoneCat]

Незнаю, я в последнее время остановился на подходе:

assert('is_string($sText)');
assert('is_numeric($iNumber)');

На assert при желании можно еще повесить свой обработчик, мой например просто складирует сообщения в иерархии вида: «файл -> класс -> метод -> строка», ну или «файл -> функция -> строка», легко можно найти где произошла нестыковка, да и при желании assert можно легко отключить.

[@j4ck]

Делаем PHP строго типизированным
habrahabr.ru/blogs/php/38592/