PHP 5.3 - стоит ли на нем писать?

[zerkms]

grigori
пардон, что отвечаю за автора фразы, но почему бы не The Proxy Pattern? Самый типичный паттерн для магического _call.

 

[whirlwind]

zerkms ага, еще декоратор. Проблемы начинаются когда начинаешь писать. Без типов можно все что угодно сделать, но код становится нечитаемым.

 

[AmdY]

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

 

[grigori]

Автор оригинала: triumvirat
да? строгая типизация? а я как-то пропустил. круто!

нет, и не будет. кажется, Размус сказал: "it's not a PHP way"

впрочем, специально для экстремалов сделали
http://php.net/manual/en/book.spl-types.php


zerkms, AmdY
мне просто любопытно чтение описаний паттернов дает пищу для размышлений

 

[zerkms]

"чужих" ??

 

[grigori]

ага, читать о своих (тех, что я часто юзаю сам) обычно неинтересно

 

[AmdY]

мне нравится с помощью магии избавляться от геттеров-сеттеров

/**
 * @property-read string $id
 * @property-read string $login
 */
class foo {
public $title;
public $content;
public function setTitle($value) {
$this->title = htmlspecialchars($value);
}
public function __call($key, $value) {
//отрезаем set от key, проверяем существование и присваиваем  
}
}
$o = new foo();
$o->setTitle('<b>test</b>'); // срабатывает так как существует
$o->setContent('<b>test</b>'); // срабатывает __call

в классе Auth, с учётом того, что поля с данными о пользователе из проекта в проект часто меняются, а класс переписывать каждый раз не будешь, тоже использую магию

class auth {
    public function __get($name) {
        if (!$this->isAuth()) return null;
        return (isset($this->_session['user'][$name])) ? $this->_session['user'][$name] : null;
    }
}
$avatar = auth::singleton()->avatar; //ненужный singleton
//в 5.3
$avatar = auth::getAvatar() //через __callStatic

 

[grigori]

да, удобно
мне только одно не нравится: при каждом обращении к полю идет работа со строками, а когда этих операций много, может быть довольно заметный drawback по CPU

 

[whirlwind]

AmdY ну если доменную модель мешать с сессией, то видимо это лучшее решение. Я же говорю - каша.

PS. Но можем обсудить как сделать лучше, если интересно.

 

[AmdY]

whirlwind
конечно, интересно, если это останется таким же удобным.

 

[whirlwind]

Ну вот ты можешь однозначно описать зону ответственности класса auth? Он хранит атрибуты юзера, хранит данные сессии или реализует алгоритм авторизации?

 

[AmdY]

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

 

[fixxxer]

Вопрос реализации интерфейса __call не решает.

По сути, просто вариация на тему dispatch('method'). Притом неявная.

Для pure value objects я предпочитаю перегружать геттеры и сеттеры (а у иных и не должно быть никаких getTitle/setTitle ибо нефиг).

 

[whirlwind]

Вот если бы он у тебя занимался аутентификацией, класс User представлением пользователя (рассказать о нем), класс Session отвечал за хранение любых переменных (просто удобный стораж), то мухи были бы отдельно и никаких __callStatic тебе бы не понадобилось. А так, вот я глянул на код, вроде один класс, назван понятно, но название свое не оправдывает. Что делать, что бы узнать его зону ответственность? Лезть и ковырять код! Кому это удобно, как ты выражаешься? Буэээ...

 

[AmdY]

да, но это всё усложняет. название действительно путает.