mephius писал(а):
Да, книжные. В вашем случае использование глобалсов не катастрофическое, там по сути очень просится простенький registry. Есть по коду еще несколько мест, где этот же реестр будет полезен. Код сложнее не станет, ни медленнее, ни быстрее не стенет, но зато будет читабельнее, чуток быстрее можно будет искать что к чему, и добавится удобный инструмент, когда понадобится еще что-нибудь вынести в "глобал". Вот явный индикатор того, что вам нужен реестр:
Registry, кроме минимального повышения читаемости, не даёт в данном случае ничего. При использовании strict неправильное обращение приводит к исключению, которое соответствующим образом обрабатывается и показывается. Т.о. главный полезный эффект от registry покрывается стандартными средствами.
Работа с массивом в PHP практически не отличается от работы с объектом. Т.е. введением registry ты по сути переименуешь GLOBALS в Registry. Как без этого до сих пор всё работает - неизвестно.
mephius писал(а):
Собственно, по поводу "излишней книжности". Книжки они пишутся на опыте, и брать из них нужно именно опыт, а не догмы, мол, так делать нельзя, а нужно только вот так. К примеру, те же паттерны проектирования -- это, так сказать, best practices решения тех или иных архитектурных задач. Это не означает, что они должны быть абсолютно везде, это означает, что не нужно изобретать велосипед для решения типичных кейсов. Ну как вот здесь с глобалами и registry, например.
Буквально - открыл глаза. Ведь я этого, конечно же, не знал.
mephius писал(а):
Возможно, вам с коллегой по TVonTop стоило терпимее относиться к позициям друг друга, тогда польза была бы для обоих.
Возможно, нет.
mephius писал(а):
Кстати, ультимативная форма общения не подойдет. Мне нет необходимости вам либо еще кому-то что-то доказывать, а значит и принимать условия ультиматума =)
Покуда я не увижу пользы, ты отнимаешь моё время. А это очень и очень ценный ресурс. Особенных надежд, на то что из этого разговора выйдет какой-то толк, я не питаю. Поэтому так. Если это не устраивает - ты всегда можешь прекратить сюда писать. Ничего личного.
mephius писал(а):
По поводу парсинга. Я уже говорил, что у нас только один пользователь. Вопрос производительности в таком случае у нас возникает, когда тормоза в том или ином случае видны на глаз. Если бы у нас было хотя бы 20-30 тысяч пользователей онлайн на одном и том же апп-кластере,
В этом и есть корень проблемы. Ты привык работать с апп-кластером на 20-30 тысяч пользователей и пытаешься перенести сюда известные тебе решения. Отчёт, что это неправильно, себе отдаёшь, но изменить не можешь. Начни с изучения предметной области и доступных средств. Потом попробуй с ними поработать. Взгляд на многие вещи изменится радикально.
mephius писал(а):
то чистка html-а регекспами и прочий закат солнца вручную в ParserTools вылез бы сильно боком. Допускаю, конечно, что php на плеерах сильно ограничен и различается в разных моделях, но не настолько же.
Давай сюда примеры немотивированного использования регекспов. ParserTools именно для того и был написан, чтобы минимизировать их использование.
mephius писал(а):
Кстати о ParserTools. Он у вас встречается довольно часто. Это хороший кандидат на то, чтобы убрать его явные статические вызовы и заменить его получение через тот же реестр. Это нужно затем, чтобы обеспечить слабое связывание (low coupling). Высокое связываение сильно усложняет жизнь, например, при написании тестов к коду или при попытках повторно использовать код.
Чем ты хочешь динамически заменять ParserTools?
Попробуй ответить на этот вопрос, прежде чем объяснять мне про слабое связывание.
mephius писал(а):
А тесты бы пригодились для выявления вот таких ошибок, как в у вас в классе ConfigFile:
Код: Выделить всё
if (! empty($this->password)) {
$contents = ParserTools::encrypt($contents, $this->password);
}
Здесь обычная опечатка, переменная $contents не определена в контексте ConfigFile::writeFile(), там определена переменная $content. Как результат, содержание не криптуется даже если задан пароль.
Тесты вообще хороши как для самого кода, так, в случае ГлавТВ для проверки всех сервисов на предмет того, не изменилось ли у них чего в выдаче и не нужно ли подстроить парсинг.
Хорошо ли тебе понятна разница между коммерческим энтерпрайз проектом (читай: апп-кластер на 20-30 тысяч пользователей) и хобби проектом, изначально движимым двумя людьми? Невольно возникает вопрос, знаешь ли ты правильные соотношения кол-ва комментариев к коду и кол-ва кода к тестам?
mephius писал(а):
Лапша в темплейтах. Есть же хорошие удобные средства работы с xml. Почему бы не использовать? А то логику вычитывать из этого спагетти -- это без поллитра никак. И сорвались с ОО стиля на процедурный в rss-funcs и rss-design. Или осталось как легаси?
Легаси.
Про хорошие удобные средства работы с xml. Это, кстати, для php они хорошие и удобные? Неважно. На апп-кластере с 20-30 тысячами пользователей ты всё сам установишь. А тут у тебя есть то, что предоставит коробка (одна из тысячи, см. список поддержки) и то, что ты с собой принёс.
А логику вычитывать ниоткуда не надо. Это на АКС23ТП тебе нужно обеспечить читаемость и понятность. А тут, как показала практика, граждане лезут в код ровно с одной целью - отломать весёлые картинки "Помоги проекту". Поэтому повышение читаемости, как задача, больше не стоит. Намеренно усложнять и спагеттизировать код у меня не поднимется рука, но делать его понятнее - просто нет объективных причин.
(некий IE)
