Процедурный подход в PHP и ОО. Налицо несовместимость синтаксиса.

[whirlwind]

C_TIGER все равно не поверите, если скажу что E_ALL | E_STRICT и никаких сообщений в еррор логе?

 

[cDLEON]

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

 

[whirlwind]

PS. Вырвал изх первого попавшего под руку конфига http://phpclub.ru/paste/2402

 

[cDLEON]

Этим, кстати, меня и манит ТДД, но для меня очень трудно осилить лень, связанную с написанием кучки тестов....
whirlwind
Я - поверю. У меня тоже нет ни каких ошибок. Даже на 5.3....

 

[HraKK]

Когда уже Саша перенесет пхпклаб, и Тигра отправят в рид онли...

 

[C_TIGER]

whirlwind
а при чём тут?
cDLEON
никто же не запрещяет включить


HraKK
как говорится, кто громче всех кричит, тот....

-~{}~ 16.02.10 23:20:

короче
if($var['key']) = notice
+ error_reporting({without notice});
+ handling errors
нет ничего плохого. конец истории =)

точнее много лучше чем для этого использовать всякие ArrayObject'ы

 

[Духовность™]

это говнокод, поражающий хаос

 

[C_TIGER]

хаос поражает не это, а "какая-то грёбанная буковка введёная по ошибке в ключе массива"

 

[AmdY]

Автор оригинала: Fortop
AmdY
Не надо мне манов, я их знаю возможно даже несколько лучше Вашего.

Вопрос был в другом, если Вам нужно поведение объекта в foreach - реализуйте соответствующий интерфейс. Какое это имеет отношение к обычным массивам?

в обычным массивам имеет отношение ещё один интерфейс входящий в ArrayObject - ArrayAccess, что не понятно?
И что за комплексы с публичными свойствами, почему это не ООП? лишние геттеры-сеттеры это как раз ООП ради ООП.

$this->getRequest()->user_id->toInt() - это вообще никак не влияет на отладку, т.к. просто синтаксический сахар

$id = $this->getRequest()->user_id->toInt();
if ($id) {....} else {}
но очень помогает при разработке $id = $this->getRequest()->user_id->toInt(7); - значение по умолчанию
$this->getRequest()->user_id->toInt(new Exception_Bad_Param('не передан ид пользователя')); - а это мы избавились от ветвления if () с помощью выбрасывание исключения. Но если вам нравится писать тоны кода ради большей ООП-ности - пожалуйсто.

 

[Fortop]

что не понятно?

Непонятно какое отношение имеют массивы к итерациям.
Если Вам нужно только итерировать объект - зачем делать миллион лишних телодвижений и превращать объект в массив?

И что за комплексы с публичными свойствами, почему это не ООП?

Говорят инкапсуляция жутко помогает.

лишние геттеры-сеттеры это как раз ООП ради ООП.

Они не лишние. Их или не должно быть или они должны быть для всего. Работать с винегретом крайне неудобно.

В этом плане весьма удобны __get/__set они позволяют прозрачно подключать геттеры и сеттеры по-требованию.

 

[AmdY]

Говорят инкапсуляция жутко помогает.

помогает, где надо и мешает где не надо. если бы мешали, то их давно бы выбросили.

В этом плане весьма удобны __get/__set они позволяют прозрачно подключать геттеры и сеттеры по-требованию.

+1 я том же

 

[cDLEON]

C_TIGER
Т.е. для вас абсолютно не важно, что в момент проверки данных, могут быть отправлены не все заголовки? И включение вывода ошибок выведет скрипт из строя?

 

[dimagolov]

cDLEON, это не аргумент. ошибки можно выводить и в лог.
другое дело, что когда вылазит куча нотисов, которые "должны быть" понять где среди них те, которых "быть не должно" и которые ошибки, совершенно нереально.

кстати, заметное кол-во тех же E_STRICT в 5.3 на достаточно нагруженном сайте весьма быстро (до 50 часов) загоняет размер лога ошибок в 2Гб и валит php-fpm, который файлы больше 2Гб, в отличии от mod_php, не переваривает.

 

[fixxxer]

>>Они не лишние. Их или не должно быть или они должны быть для всего. Работать с винегретом крайне неудобно.

если тебе постоянно нужны геттеры-сеттеры для скаляров, твоя архитектура говно ничуть не меньшее чем если бы это были паблики

 

[Fortop]

если тебе постоянно нужны геттеры-сеттеры для скаляров

Мне? Я вообще не перевариваю геттеры/сеттеры везде. Но скажите об этом авторам ZF.

Я в упор не вижу смысла когда весь код геттера и сеттера содержит только присваивание без какой-либо обработки.

Моя же мысль о том, что вот такое

$obj->value1
$obj->getValue2()

крайне неудобно.

Так

$obj->getValue1()
$obj->getValue2()

или так

$obj->value1
$obj->value2

много лучше. Причем мне нравится больше 2й вариант.

 

[korchasa]

Fortop
Ну да. Зачем все это придумали. Разве бывает так, что требования меняются, и getValue() вдруг начинает требовать какой нибудь логики.
Да даже если так. Ведь всегда можно задействовать __get. А там внутри switch($method_name) и понеслась.

 

[fixxxer]

Вопрос не в том. Вопрос в том, что ни $obj->value, ни $obj->getValue() в нормальной архитектуре нет (если, конечно, речь не об ArrayObject и подобных реализациях, предназначенных только для хранения значений).

 

[korchasa]

fixxxer
А что вместо них? Есть у пользователя имя, например. Его надо выводить в письмах, на страницах и т.д. Как это будет выглядеть в вызове?

 

[Fortop]

korchasa

Ну да. Зачем все это придумали. Разве бывает так, что требования меняются, и getValue() вдруг начинает требовать какой нибудь логики.

Прошу прощения, но Вашей мысли совсем не понял.

Как это будет выглядеть в вызове?

Я подозреваю так.

Приказ № 12312
Организовать авторизацию пользователей на корпоративном портале.

2010.02.17                                                         Подпись

 

[AmdY]

korchasa
зачем switch? method_exists и вызов нужного метода, если есть.