Pull to refresh
47
0
Oleg Botvenko @bo2

Chief Technology Organism

Send message
Да, Хабр такая штука, только ты опередил график, я как только задумаюсь о том, как бы сделать что-то, так сразу на Хабре статья появляется с подробной инструкцией)) Раз 5 уже такое было.
Появляется, только что добавил в телефоне «Годовщину», появилась в календаре.
В Гугле есть «Адресная книга» и «Все контакты» В адресную книгу нужно явно добавлять, она и синхронизируется
Да, действительно мелкие… Не исправили это
У меня дома и на работе WiFi, я настроил синхронизацию на рабочее время.

А вообще 3.5 грн за мегабайт — Билайн Украина, есть тарифы и подешевле, а синхронизация немного трафика ест, если ее раз в час, например, сделать.
Я знаю, не хами.

Тогда в начале кода вместо вызова одной функции будет вереница из объявлений global
Какой ты резкий))

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

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

Полное разделение логики и представления — это как коммунизм, очень заманчиво, но пока нереально.
Интересная возможность, тогда в качестве namesapce выступает функция.
Но немного не подходит для передачи данных между скриптами, а $GLOBALS слишком громоздко в коде смотрится.
Понятно, по сути переменные от классов и не отличаются, глобальный класс или глобальная переменная, какая разница, считайте глобальную переменную классом с одним полем.

Zend_View — это и есть по сути namespace, в этом его основное назначение, единственное, что в коде везде префикс "$this->" мельтишит, было бы хорошо, чтобы и его не было.
Т.е. Вы предлагаете сделать некий класс и в его static-члене хранить переменные для передачи между скриптами?
Это все верно, но кроме одного случая — передачи переменных в HTML-представление.

HTML-код должен быть «экстремально» удобочитаемым (иначе можно разориться на верстальщиках), поэтому нужны простые и лаконичные переменные, которых в природе очень мало.

А что Вы подразумеваете под объединением классов и функций?
)) Это я про код бизнес-логики системы.
Спасибо, не знал про такую функцию, первый раз просто столкнулся с подобной проблемой. Код упрощается.
Вы слишком категоричны)
Костыль — это решение, которое может привести к проблемам в будущем. В чем вы видите возможные проблемы с таким решением?

Я посмотрел несколько примеров приложений на Symfony, там тоже стремятся использовать короткие понятные переменные для передачи данных в шаблоны. Вы вообще считаете пространства имен дурным тоном, как goto, например?
Это всего одна глобальная переменная с «некрасивым» именем (т.е. с небольшой вероятностью повторного использования), вместо нескольких переменных с короткими и часто употребимыми именами.

Вообще я считаю, что для крупных систем, ясность и лаконичность кода — это одно из самых важных требований, поэтому переменные с именами $order, $client, $id, $pay и т.п. очень востребованы, если использовать вместо них какие-то глобальные классы с длинными именами, то читаемость кода сразу сильно ухудшается.

Думаю, что код в идеале должен читаться как простая английская речь.
А чем Вас пространства имен в PHP 5.3 не устраивают в целом?
Это используется для разделения логики и представления, в первом скрипте генерируются данные, во втором — HTML-код. При генерации HTML кода хочется использовать PHP-вставки с простыми и понятными именами переменных, например <? echo $order['num'] ?>, а не <? echo $DATA['this_page']['order']['num'] ?>

При этом между первым и вторым скриптом вполне может выполняться другой код, в котором тоже хочется использовать простые и понятные переменные.

Как это можно по другому реализовать?
8 ГБ, 4 ядра получается почти $300, железный можно за $200 снять

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity