Comments 32
Куда опустить бюллетень лицевой стороной вниз, что я против?
Если честно, то я ничего не понял.
Речь идет о запрещении использования $_GLOBALS и global?
- Начинаешь холиварную (или просто странную) тему.
- Просишь не начинать холивар.
- ???
- Все вокруг плохие, т.к. начали холивар и не поддержали автора
А в каком месте статьи был представлен "научный подход"?
И где в посте "здравая аргументация"? Является ли "исходя из моего опыта в веб-программировании" — достоверной и здравой аргументацией или всё-таки это ИМХО?
А обращение к "свободно мыслящим" — умышленное принижение и оскорбление всех несогласных. Очень научный подход.
Пример с пометкой "no holy war":
что лучше ios или android? No holy war, please!
или всё-таки это ИМХО?
естественно имхо.
А в каком месте статьи был представлен «научный подход»?
Его не было. Была просто представлена идея, которую предлагалось обсудить
А обращение к «свободно мыслящим» — умышленное принижение и оскорбление всех несогласных.Не согласен. Я не писал «свободно мыслящие, которые поддерживают мою идею...» Человек может быть свободно мыслящим и не соглашаться при этом со всем и вся.
- А в каком месте статьи был представлен «научный подход»?
- Его не было.
Но ведь в самом начале статить написано было, что будем обсуждать:
Я бы сказал, это научный вопрос, который хотелось бы обсудить.
А сейчас ещё оказывается, что всё это:
естественно имхо.
Т.е. мы обсуждаем научный вопрос оперируя исключительно ИМХО? Браво! Мне кажется, что слово "научный" было добавлено исключительно, чтобы потешить ЧСВ автора, т.к. реальных и подкреплённых аругментов, кроме ИМХО тут не представлено.
И berez (комментарий, которого старательно игнорирутеся, хотя другие комментарии не остаются без внимания) уже опроверг "мнение" о производительности обоих подходов.
естественно имхо.
Я думаю что Хабр — не очень подходит для такой дискуссии. Тостер или пхпклуб или реддит подойдут больше.
Но в любом случае надо гораздо четче формулировать свои мысли — как предпосылки, так и предложения.
Автор, если «писаки» какого-то софта, не имеют в руках инструмента (навыка, способности) определить дубли объявления, или изменения переменных — это только их (писак) проблемы.
Нормальные разработчики, считают нужным использовать глобальную область видимости для переменных — используют, перед выходом в продакт проверяют на дубли объявлений и корректность перезаписи значений. Если считают, что в этом коде нужно обойтись без глобальных переменных — обходятся. Никакие паттерны/антипаттерны им не нужны, есть задача, есть группа, имеющая общие соглашения о правилах именования и распределения переменных (как правило вводный файл для любого нового разработчика, присоединяющегося к работе над конкретным кодом) — всё, остальное лирика «писак».
Намного быстрее обратиться к переменной напрямую, чем предварительно передавать ее значение через стек. Имеется ввиду, стек процессора, который используется компиляторами для передачи параметров функций.
Что за бред я только что прочитал?
Передача значения через стек — это стандартная процедура, выполняемая миллионы раз в секунду. Да и не обязательно передача аргументов выполняется именно через стек. Например, в архитектуре x86_64 первые энцать аргументов передаются через регистры процессора. Зависит, конечно, от используемого ABI.
Обращение к переменной напрямую — весьма вероятный cache miss со всеми вытекающими.
Обращение к переменной в стеке — никаких промахов, т.к. стек с очень большой вероятностью закэширован.
В связи с этим, прошу свободно мыслящих людей высказать свое аргументированное мнение на вопросы:
поддерживаете ли вы введение экспериментальных функций super() и stop_globals()?
Я не свободно мыслящий, т.к. ограничен в своих размышлениях объективной реальностью. Но таки отвечу: не поддерживаю.
Ибо после введения таких функций в «большом синем слоне» что-нибудь неминуемо отвалится. Вы можете навскидку перечислить модули, использующие глобальные переменные для своей работы? Я вот нет.
что думаете о вышеописанной идее в целом?
Я вам расскажу старый анекдот.
Приходит молодой сисадмин к старому и опытному, и говорит:
— Хочу, чтобы пользователи не нажимали на вот эту кнопку. Какую программу лучше использовать, чтобы они не смогли это сделать?
Старый сисадмин вздохнул и ответил:
— Просто собери их всех и скажи: «кто нажмет на вот эту вот кнопку — пооткусываю пальцы». И кусачки покажи.
Мораль сей басни такова: технические средства решения проблемы не обязательно лучшие. Иногда гораздо лучше работают административные меры или банальная дисциплина.
Возвращаясь в тему поста, с недавних пор появился phpvote и существует достаточное количество источников куда вы можете обратиться со своей идеей где есть возможность глубоко подискутировать (хабр все же площадка не для этого)
в чем вы видите тупиковую ветвь развития?
Наличие большого количества фреймворк для веб-разработки говорит об этом. Дороговизна создания ПО. Наличие большого количества ошибок в продакшн коде и отсутствие хорошего формального подхода в производстве ПО. Я верю, что ситуация со всем этим должна/может быть лучше, конечно ИМХО.
Использовать глобальные переменные — плохо.
Давайте использовать глобальные переменные, но через кастомную функцию!
Автор, вы пытаетесь решить глобальную проблему очень кривым костылем.
Считаю именно этот факт, а также свободное мышление его автора, позволило этому проекту стать столь популярным, каким он есть.
Вы путаете свободу мышления и неумение спроектировать архитектуру под соусом "очень-очень удобно"
неумение спроектировать архитектуру под соусом «очень-очень удобно»Уже более 15 лет, область веб-программирования развивается жадными темпами всем мировым сообществом программистов, а бекэнд фреймворка нет и нет, который был бы столь же популярен как и jQuery. Вы пишите laravel это от неумения…
Я бы применил такой научный подход: найти статистические данные на скольких сайтах в Интернете реально используется jQuery и на скольких самый популярный бекэнд фреймворк. Далее идет ненаучный подход, а моя интуитивная оценка: jQuery используется на 50% сайтов, по бекэнд ситуация плачевная — большой разнобой. 3% laravel, 5% symfony (за счет того только лишь, что более старый) и далее список по 1 и менее процентов, в том числе Perl и куча не PHP технологий. Исходя из этих статистических данных, я делаю вывод: имхо, ситуация с обработкой в браузере лучше чем на бекенд. jQuery это удачное решение, а по бекэнду его нет. Не знаю сколько людей здесь могли бы со мной согласиться. В следующем выводе согласится еще меньше: проблема кроется глубже, мы имеем неверные догмы и стандарты.
Конечно, нет 100% корреляции javascript и бекэнд в этом аспекте сравнения, но имхо, она имеет высокий коэффициент.
а бекэнд фреймворка нет и нет
Symfony? Он не без какуль но все же.
найти статистические данные на скольких сайтах в Интернете реально используется jQuery
И что вы этой статистикой хотите понять? Что большая часть сайтиков на вордпресиках, джумлах да друпалах с опенкардами? Эти цифры, даже если бы вы их получили буквально ничего не значат.
jQuery это удачное решение, а по бекэнду его нет.
Собственно и что? На момент создания — эта либа упрощала жизнь. Сейчас есть куча других более лучших. В пыхо мире раньше CI был в популярен, а что сейчас? Идеи, заложенные в этом фреймворке не актуальны.
Я бы применил такой научный подход
очень жаль, что в статье был представлен "естественно ИМХО", а не научный подход.
peresada, писал: «Что-то мне подсказывает, что суммарный код бекенда среднего сайта во много раз превосходит суммарный код фронтенда»…
Ну и что? Я могу сказать за себя точно, поверьте, если бы была доступна для меня нормальная бекэнд среда для разработки, я бы ничего не изобретал и не выдумывал, вот поверьте, честно. Но существует куча технологий. Как вы думаете почему появляются новые? Вероятно из-за того что не устраивают имеющиеся и не устраивают по нюансам их использования.
Всем спасибо и с праздником программиста!
если бы была доступна для меня нормальная бекэнд среда для разработки
Почему для остальных людей она доступна, а для вас не доступна?))
Как вы думаете почему появляются новые? Вероятно из-за того что не устраивают имеющиеся и не устраивают по нюансам их использования.
Меняются задачи, а старые решения их не поддерживают, по этой причине ведется поиск новых решений.
Но все же задача с глобальными переменными в пыхе — далеко не новая.
То, что вы в статье предлагаете — это просто костыль, который вам показался удобным, не более того. В крупных проектах на передний план выходит целая серия требований:
- легкость чтения
- легкость поддержки и расширения
- безопасность
- переносимость
- тестируемость
- производительность
- надежность
А ваша хотелка с мнимым удобством — это просто хотелка.
давайте сделаем 4 пробела для отступа вместо одного символа табуляции, так будет надежнейПри чем тут надежность, и почему нет? Тебе как набирающему код должно быть вообще все равно, потому что это настраивается в редакторе кода.
Нет вообще никакой нормальной среды разработки.
Тут в 2018-ом есть PhpStorm, а вы из какого года пишете?
Вы не можете отстрелить себе ноги, но вы добровольно уже отрезали себе руки. Догмами, PHP right way и PSR.
Если у вас нет понимания и умения выполнять некоторые правила / стандарты — о каких руках может идти речь?))
давайте сделаем 4 пробела для отступа вместо одного символа табуляции, так будет надежней.
В "надежность" вкладываю прогнозируемость работы системы в случае, если какая-то из частей отвалится по произвольным причинам, а вы 4 пробела...
Бред это… бред…
Бред — это ваша упоротость на не желании понять, зачем нужны вот эти всякие стандарты и почему их следует придерживаться, с головой конечно же.
Когда же уже некто из ваших вождей вам скажет об этом, чтобы вы все проснулись…
… у меня вождя нет, ни одного, а что ваш думает по этому поводу?
То, что вы ларку в пример ставите — это конечно круто, но для мелких проектиков.
Тут вопрос был про CodeReview, возможно вам пригодится https://toster.ru/q/276441#answer_723827
1) Глобальные переменные это плохо, потому-что можно затереть эти данные.
2) Давайте везде отключим глобальные переменные. Нет возможности выстрелить в ногу = нет проблем.
3) Ну ладно, давайте оставим возможность иногда ЧИТАТЬ глобальную переменную, а записывать через костыльную функцию, чтобы пользователь точно_понимал_что_делает.
Собственно я не сторонник что-то запрещать и выкидывать из языка, это всё дело конкретных ситуаций и вкусов. Более того, наверняка много где встречается разного качества код, который так или иначе будет зависеть от некой глобальной переменной очень неявным образом так, что замена глобальной переменной будет стоить переписывания бОльшей части кода, и в итоге проще будет оставить глобальные переменные включёнными и иногда делать codereview, чем переписывать весь в мире код.
Ну это, как всегда, странно пинать глобальную область видимости — она есть в языке как данность и всё тут. Если даже абстрагироваться от фреймворков и прикинуть, что вы собрали свою мини-подделку, например из головы, или же из того, что нашлось на просторах packagist, — ваша глобальная видимость, по идее, заканчивается на запуске приложения/каркаса/фреймворка — эта точка, где ваше приложение переезжает вариться в вереницы обьектов, которые изолированы от глобальной области видимости, в которую можно вернуться назад только средствами ключевого слова global.
Пример про то, что "неудобно использовать Dependency Injection" явно демонстрирует ваше неполное понимание того, как готовить такую архитектуру и опять же вызывает вопрос, который, вы, словно, специально опускаете, — с чего вдруг они (база данных | пользователь) должны быть в глобальной области, а не прокидываться куда/когда надо? Если бы вы сами не выкидывали обьекты в глобальную область для чтения позже, то не нужно было бы даже и статью писать, наверное… Да и опять же… Если не сильно грешить, то можно такие вещи, которые вы привели в пример, оформить как singleton, если уж так приспичило куда-то зачем-то лазить, вместо того, чтобы принимать то, что требуется.
Плохи не глобальные переменные, плохо глобальное состояние. От того, что вы замените суперглобальный массив $_GLOBAL (или его аналог в других языках) на, например, репозиторий с синглтонами, фабриками и DI, станет только хуже т.к. состояние как было глобальным, так глобальным и осталось, но зато, у вас появилась куча вспомогательных сущностей, усложняющих понимание кода.
Правильный подход (опять же ИМХО) — это отказ от глобального состояния везде, где это возможно и оправдано, не важно, каким именно способом оно организовано. Если же это не возможно (например, объект глобален по своей бизнес-логике), то организация доступа к нему должна быть максимально проста, насколько это позволяет остальная архитектура вашего приложения, в том числе это может быть и $_GLOBAL.
Глобальные объекты в PHP