> Плюс есть человеческий фактор. С плохо написанным кодом постепенно полностью пропадает желание работать, полгода, максимум год — и программист сойдет с ума (горький опыт :) ).
Мне, как программисту, очень интересно решать задачи, которые не каждый решать возьмётся. Может это и IT-мазохизм, но для меня это интересно. Решать задачки по книжке конечно круто, радоваться потом какой умный ход и т.п., но в реальности задачи бывают намного жёстче.
Конечно, когда не можешь найти решение — проще всего всё бросить, плюнуть и говорить какой нехороший код, но когда можешь — хочется работать и улучшать.
> У меня относительно небольшой опыт работа с пхп, но на код я успел насмотреться всякий. Что касается 2 строчек, я же прекрасно себе представляю, зачем их написали (чтобы оставить глоб. переменные, только теперь их профильтровывают через функцию), и куда они дальше идут. Еще раз говорю, вам это плохой и бесперспективный код, все равно его придется рано или поздно выкинуть. И написать так, как я сказал :) Ну или свой велосипед изобретать и мучаться с проблемами разными.
> Лол, да это же те же глобальные переменные, только по другому называются!
Принудительная регистрация переменных из суперглобальных request массивов и выборочная регистрация переменных из явно указываемых массивов — не одно и то же! Ваше высказывание — глупость.
Вот я совсем не против если мне начальство ещё каких нить книжек прикупать будет, много книжек не бывает!
> Часто (то есть в 95% случаев) данные и методы их обработки можно надежно убрать в объект.
Убираются, и весьма успешно. Вот только писать с нуля и переделывать систему которой 10 лет — не одно и то же. Совместимость должна остаться, попробуйте сначала решить такую задачу.
> Вы что, не можете сделать для входных перемнных класс вроде HttpRequest, как во всех приличных фреймворках и передать дальше? не загрязняя область глоб. переменных? Поверьте. так намного удобнее. Это же не код, а лапша какая-то, что тут написано. так уже лет 10 никто не пишет, да и не писал никогда ни один нормальный разработчик.
Как интересно, прочитав две строчки кода, уже советуете какие классы написать и как их использовать. Видимо впечатляющий опыт рефакторинга за плечами сказывается!
> Это как джумла или друпал, люди толком не разобрались, как делаются большие системы, и пошли лепить как придется.
EXTR_SKIP не позволит перезаписать существующие переменные. Могут возникнуть проблемы, например с $DOCUMENT_ROOT из файла vars.inc.php. Сначала следует протестировать на существующих проектах, потом уже можно будет об этом говорить. За предложение спасибо.
> 2)… Почему нельзя сделать Message->add(array) и чтобы в нем обрабатывались все действия. Почему для работы с компонентами до сих пор приходится использовать запорсы к базе данных а не перевести их на ORM.
То, что лежит в директории /netcat/system/ как раз для того и делалось. Для начала переписали базовый функционал получения данных, т.к. это даёт больше прироста производительности, в дальнейшем классы расширятся. В той же директории есть папка essences, в ней есть файл nc_message.class.php, функционал добавления сообщений появится в нём, по срокам ничего не буду говорить, т.к. это не ко мне. Выходит, что мы думаем об одном и том же)
> 3) Было бы очень удобно, если код компонентов вынесли из бд в локальные файлы. Работы тут немного, а плюсов — куча.
Тут спорный вопрос, файлы или БД — почти холивар. Уж точно не предмет первой необходимости.
1. Роутинг будет обязательно, новое API позволяет это реализовать в ближайшее время;
2. Система событий уже есть в системе, пока не документирована т.к. тестируется. Есть события на добавление, редактирование, удаление сообщений и прочих сущностей, в т.ч. и пользователя. Мы не топчемся на месте, стараемся развиваться, но на всё нужно время.
Для каждой задачи можно найти альтернативное решение. Файл vars.inc.php — конфигурационный файл системы, пихать туда свои переменные уже не очень хорошо. Зачем делать то, от чего хотите уйти?
Да уж, святая дискета вам не поможет, слишком ненадёжен носитель. Ещё несколько итераций назад было написано, что не стоит навязывать другим своё мнение.
Прежде чем высказываться о ком то, нужно самому быть кем то.
И всё равно не убедительно. Коль уж утверждается, что у человека и шимпанзе общий предок, то вряд ли он был птицей… скорее та же обезьяна. Вот только я в это не верю. Вы уже запутались в собственных домыслах, действительно, осталось только в схоластику удариться.
спасибо
> А вот вторая половина — чистой воды перечисление хреновин которые придумались.
Это плохо?
Мне, как программисту, очень интересно решать задачи, которые не каждый решать возьмётся. Может это и IT-мазохизм, но для меня это интересно. Решать задачки по книжке конечно круто, радоваться потом какой умный ход и т.п., но в реальности задачи бывают намного жёстче.
Конечно, когда не можешь найти решение — проще всего всё бросить, плюнуть и говорить какой нехороший код, но когда можешь — хочется работать и улучшать.
> У меня относительно небольшой опыт работа с пхп, но на код я успел насмотреться всякий. Что касается 2 строчек, я же прекрасно себе представляю, зачем их написали (чтобы оставить глоб. переменные, только теперь их профильтровывают через функцию), и куда они дальше идут. Еще раз говорю, вам это плохой и бесперспективный код, все равно его придется рано или поздно выкинуть. И написать так, как я сказал :) Ну или свой велосипед изобретать и мучаться с проблемами разными.
ИМХО — недальновидный бред!
Принудительная регистрация переменных из суперглобальных request массивов и выборочная регистрация переменных из явно указываемых массивов — не одно и то же! Ваше высказывание — глупость.
Вот я совсем не против если мне начальство ещё каких нить книжек прикупать будет, много книжек не бывает!
Убираются, и весьма успешно. Вот только писать с нуля и переделывать систему которой 10 лет — не одно и то же. Совместимость должна остаться, попробуйте сначала решить такую задачу.
> Вы что, не можете сделать для входных перемнных класс вроде HttpRequest, как во всех приличных фреймворках и передать дальше? не загрязняя область глоб. переменных? Поверьте. так намного удобнее. Это же не код, а лапша какая-то, что тут написано. так уже лет 10 никто не пишет, да и не писал никогда ни один нормальный разработчик.
Как интересно, прочитав две строчки кода, уже советуете какие классы написать и как их использовать. Видимо впечатляющий опыт рефакторинга за плечами сказывается!
> Это как джумла или друпал, люди толком не разобрались, как делаются большие системы, и пошли лепить как придется.
Это всего лишь предположение.
То, что лежит в директории /netcat/system/ как раз для того и делалось. Для начала переписали базовый функционал получения данных, т.к. это даёт больше прироста производительности, в дальнейшем классы расширятся. В той же директории есть папка essences, в ней есть файл nc_message.class.php, функционал добавления сообщений появится в нём, по срокам ничего не буду говорить, т.к. это не ко мне. Выходит, что мы думаем об одном и том же)
> 3) Было бы очень удобно, если код компонентов вынесли из бд в локальные файлы. Работы тут немного, а плюсов — куча.
Тут спорный вопрос, файлы или БД — почти холивар. Уж точно не предмет первой необходимости.
2. Система событий уже есть в системе, пока не документирована т.к. тестируется. Есть события на добавление, редактирование, удаление сообщений и прочих сущностей, в т.ч. и пользователя. Мы не топчемся на месте, стараемся развиваться, но на всё нужно время.
этот модуль и так всегда загружается, объясните задачу подробнее.
$_NETCAT_INPUT = $nc_core->input->prepare_extract();
потом уже:
extract($_NETCAT_INPUT);
В чём смысл от этого отказываться?
Прежде чем высказываться о ком то, нужно самому быть кем то.
Доказательство от противного. Раз уж они настолько были подкованы, почему изначально ошибались?
Огромный «доказательный» базис, как раз таки и мешает трезво смотреть на вещи.