В сообщении пойдет речь о фундаментальном в программировании — глобальных объектах. Я бы сказал, это научный вопрос, который хотелось бы обсудить. Итак, чтобы не «отстрелить себе ноги», программисты не программируют в глобальной области. Ок, все понятно и предельно просто, остановимся на этом? Не в этом материале. Как известно любое действие вызывает цепь событий и логических следствий.
Во первых, зачем создавать догму, которую можно не создавать? Вместо нее, давайте создадим функцию stop_globals(), например для языка PHP. Фреймворк, вначале выполнения своего кода, может ее выполнить, а дальнейшие попытки работы с глобальной областью, будут вызывать ошибки PHP. Хорошо ли данное решение?
Это еще далеко не все, что можно было бы обсудить.
Главная причина существования вышеуказанной догмы в том, что имеется возможность случайно затереть значения глобальных переменных, а это, в свою очередь, может привести, в том числе к трудно локализующимся ошибкам в программе. А если иметь возможность пользоваться глобальными переменными на чтение, но не на запись?
Давайте обратим внимание на окружающую нас Вселенную. В ней существуют глобальные объекты: пространство, время, материя, энергия, возможно темная материя и энергия. Подобным образом, исходя из моего опыта в веб-программировании, есть ряд объектов, для которых неудобно использовать Dependency Injection и такие объекты по своей сути, есть глобальные. Это объект связи с базой данных, объект `USER` и другие. Для работы с такими объектами, в PHP, можно было бы ввести функцию super('sky', 'user'), которая делала бы переменные $sky и $user суперглобальными, подобно как $_GET или $_POST.
Такое решение не хуже традиционной догмы «в глобальной области программировать нельзя», так как, запись данных в такие переменные сразу обнаружится и PHP выдаст ошибку, а преимущество в следующем:
Концептуально глобальные объекты остаются глобальными, программа выглядит проще Такой подход более производителен. Намного быстрее обратиться к переменной напрямую, чем предварительно передавать ее значение через стек. Имеется ввиду, стек процессора, который используется компиляторами для передачи параметров функций. Так или иначе реализация паттерна DI, имеет накладные расходы на используемые ресурсы Как известно, проект PHP позиционирует себя, как слона, ввиду того что предоставляет множество подходов в программировании, большого количества функций и классов, изобилием экспериментального кода, который оценивается со временем и в будущем может быть развит или удален. В связи с этим, прошу свободно мыслящих людей высказать свое аргументированное мнение на вопросы:
Поддерживаете ли вы введение экспериментальных функций super() и stop_globals()? Что думаете о вышеописанной идее в целом? No holy war, спасибо. В заключении, хотел бы отметить свое наблюдение в отношении laravel и вреде паттернов программирования. Как известно laravel называют «кладязем антипаттернов». Считаю именно этот факт, а также свободное мышление его автора, позволило этому проекту стать столь популярным, каким он есть. Паттерны хороши для общения программистов, чтобы указать на некоторую программную сущность. Но они и вредят, путая программистов, не позволяя делать программы эффективными. Давайте делать программирование проще. Ты ищешь здесь счастье. А хочется — смысл.
Во первых, зачем создавать догму, которую можно не создавать? Вместо нее, давайте создадим функцию stop_globals(), например для языка PHP. Фреймворк, вначале выполнения своего кода, может ее выполнить, а дальнейшие попытки работы с глобальной областью, будут вызывать ошибки PHP. Хорошо ли данное решение?
Это еще далеко не все, что можно было бы обсудить.
Главная причина существования вышеуказанной догмы в том, что имеется возможность случайно затереть значения глобальных переменных, а это, в свою очередь, может привести, в том числе к трудно локализующимся ошибкам в программе. А если иметь возможность пользоваться глобальными переменными на чтение, но не на запись?
Давайте обратим внимание на окружающую нас Вселенную. В ней существуют глобальные объекты: пространство, время, материя, энергия, возможно темная материя и энергия. Подобным образом, исходя из моего опыта в веб-программировании, есть ряд объектов, для которых неудобно использовать Dependency Injection и такие объекты по своей сути, есть глобальные. Это объект связи с базой данных, объект `USER` и другие. Для работы с такими объектами, в PHP, можно было бы ввести функцию super('sky', 'user'), которая делала бы переменные $sky и $user суперглобальными, подобно как $_GET или $_POST.
Такое решение не хуже традиционной догмы «в глобальной области программировать нельзя», так как, запись данных в такие переменные сразу обнаружится и PHP выдаст ошибку, а преимущество в следующем:
Концептуально глобальные объекты остаются глобальными, программа выглядит проще
Такой подход более производителен. Намного быстрее обратиться к переменной напрямую, чем предварительно передавать ее значение через стек. Имеется ввиду, стек процессора, который используется компиляторами для передачи параметров функций. Так или иначе реализация паттерна DI, имеет накладные расходы на используемые ресурсы
Как известно, проект PHP позиционирует себя, как слона, ввиду того что предоставляет множество подходов в программировании, большого количества функций и классов, изобилием экспериментального кода, который оценивается со временем и в будущем может быть развит или удален. В связи с этим, прошу свободно мыслящих людей высказать свое аргументированное мнение на вопросы:
Поддерживаете ли вы введение экспериментальных функций super() и stop_globals()?
Что думаете о вышеописанной идее в целом?
No holy war, спасибо.
В заключении, хотел бы отметить свое наблюдение в отношении laravel и вреде паттернов программирования. Как известно laravel называют «кладязем антипаттернов». Считаю именно этот факт, а также свободное мышление его автора, позволило этому проекту стать столь популярным, каким он есть. Паттерны хороши для общения программистов, чтобы указать на некоторую программную сущность. Но они и вредят, путая программистов, не позволяя делать программы эффективными. Давайте делать программирование проще.
Ты ищешь здесь счастье. А хочется — смысл.