ООП : опрос + флуд

Crazy · 29 Апр 2005

Автор оригинала: ONK
Crazy, утверждение без доводов - простой трёп.

Вот с тебя и начнем. С утверждения:

Глобальные переменные несомненно необходимы.

-~{}~ 29.04.05 15:17:

Автор оригинала: Дмитрий Попов
Т.О. Ты хочешь сказать, что неверно использовать массивы $_SESSION, $_SERVER и $_REQUEST(и его образующие)?

Разработчики PHP имели несчастье совершить серьезную архитектурную ошибку, дав доступ к переменным запроса через $HTTP_GET_VARS и т.п. -- это были именно глобальные переменные.

Нетрудно видеть, что означенные разработчики PHP осознали это и внесли новую сущность и назвали ее "суперглобальными переменными".

Не следует обманывать здесь словом "глобальные" -- это совершенно отдельная языковая сущность (несогласные могут попровать создать свои собственные суперглобальные переменные).

Верно ли их использовать? Как правило, непосредственное их использование неразумно. Но это уже совсем другая история, не имеющая никакого отношения к глобальности переменных.

betik · 29 Апр 2005

МАКС, прикрывай, если тебе от этого станет легче.
Доки + Котерова PHP5 прочитал, правда не три дня назад. Ещё Страуструпа и книги по Дельфи. Тоже не три.

Написал несколько классов для работы с БД , файлаплода и почты. Я могу написать класс, но я в упор не понимаю, зачем себе наворачивать трудности =\

-~{}~ 29.04.05 12:35:

PS
в смысле всего несколько классов, а не покаждомупункту несколько

ONK · 29 Апр 2005

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

Нетрудно видеть, что означенные разработчики PHP осознали это и внесли новую сущность и назвали ее "суперглобальными переменными". Не следует обманывать здесь словом "глобальные" -- это совершенно отдельная языковая сущность (несогласные могут попровать создать свои собственные суперглобальные переменные).

Хех, ты просто не знаешь как реализована работа этих "суперглобальных переменных" в ПХП. На самом деле это просто глобальные переменные, которые на этапа парсировки ПХП в "опкод" вносятся в локальных таблицах имён в виде ссылок на глобальные переменные. То есть производится набор действий полностью аналогичный набору действий производимых при встрече с директивой global $var_name;

Кстати старые версии ZendEncoder не считали необходимым делать глобальные переменные типа $_SERVER, $_POST ....... "суперглобальными" (не вносили их имена в локальные таблицы имён). При исполнении таких скриптов, эти суперглобальные переменные вдруг оказывались необъявленными.

Доводы в пользу использования глобальных переменных я привёл ранее. Хотелось бы послушать о разумных способах “как без них обойтись”, и аргументы в пользу применения именно этих способов.

Crazy · 29 Апр 2005

Автор оригинала: ONK
слово "необходимы" я применил в контексте "несомненно нужны". Про способы как можно обойтись без них я упомянул, а также кратко упомянул о их кривизне.

Кроме глобальных переменных в глобальном контексте существуют функции. И их применения достаточно.

Хех, ты просто не знаешь как реализована работа этих "суперглобальных переменных" в ПХП.

Вопрос о том, как реализована та или иная языковая фича внутри движка не имеет никакого отношения к предмету разговора.

Доводы в пользу использования глобальных переменных я привёл ранее. Хотелось бы послушать о разумных способах “как без них обойтись”, и аргументы в пользу применения именно этих способов.

См. комментарий после первой цитаты (про функции). Аргумент: четкий контроль за выполняемыми операциями.

Screjet · 29 Апр 2005

Глобалы = это всего-то вредная привычка. Отнюдь не неизбежность.

Для себя так решил проблему с суперглобалами: можно пользоваться ими только в конструкторе активного объекта.

ONK · 29 Апр 2005

Кроме глобальных переменных в глобальном контексте существуют функции. И их применения достаточно.

Это как мне может функция из глобальной области видимости заменить например объект пользовательской сессии или объект управления выводом, или объект абстрактного доступа к базе данных?

К тому же засорение глобальной области видимости именами функций тоже плохая практика.

И ещё, как я понимаю предлагается вместо использования прямого доступа к параметрам конфигурационного массива применить вызов функции на подобии этого:

PHP:

function get_cnf($cnf_name){
       static $config array(..................);
       return $config[$cnf_name];
}

так вот вызов этой функции в 10 - 15 раз медленнее прямого обращения к переменной. С учётом большой интенсивности применения массивов типа $aCONFIG и $aLang мы получим значимое, во многих случаях не допустимое, снижение скорости исполнения скриптов.

Screjet, Ты предлагаешь использовать наследование через агрегацию, но тут возникают 2 вопроса.
1. Если ты создаёшь в объекте локальные копии глобальных переменных, то у тебя очень существенно расходуется оперативная память + издержки на копирование. А вышеперечисленные мною глобальные массивы и объекты обычно занимаю значительное количество памяти.
2. Если ты создаёшь в объекте ссылки на глобальные переменные, то ты фактически просто ничего не делаешь, т.к. ни от каких проблем связанных с их использованием ты не уходишь, только вносишь в свой код больше путаницы.

Screjet · 29 Апр 2005

ONK
Ничего из вышеперечисленного.
Активный объект (обычно модуль) определяет свое поведение в конструкторе, в зависимости от событий, исходящих из $_GET,$_POST,$_COOKIE. Оттуда же получает параметры. Дочерные объекты = обычно пассивные. Массив $GLOBALS вообще не используется. Он не нужен. Все програмные модули организованы по принципу старший-подчиненный. Ссылку на суперобъекты модуль получает от родителя = движка сайта. Но ему не запрещено инстансировать собственние копии суперобъектов. Напр. если ему понадобиться еще одно соединение с БД, инстансирует собственный объект БД. Вобщем все построено на инкапсуляции. Каждый объект знает только то, что должен знать.

ONK · 29 Апр 2005

Screjet, задам более конкретный вопрос, как модули получают конфигурационные переменные, фразы многоязыкового интерфейса и в какой области видимости созданы "суперобъекты".

Как происходит обработка данных получаемых из форм.

Доктор · 29 Апр 2005

Люди рассуждают о том, что выпускать микроскопы не следует, так как некоторые могут ими начать забивать гвозди...

Screjet · 29 Апр 2005

ONK
Все перечисленные стандартные параметры модуль получает, по запросу, через интерфейс с движком страницы (page API), по необходимости.
Суперобъекты создаются в ядре системы, в нем же инстансируется движок страницы, который инстансирует модули.

Как происходит обработка данных получаемых из форм.

Обработка этих данных = это задача модулей.
В конструкторе модуль-обработчик проверяет входящие параметры, если нужно, загружает валидатор, который выдает список/коды ошибок или возвращает отфильтрованные данные.
Далее модуль определяет поведение страницы посредством движка страницы.

ONK · 29 Апр 2005

Screjet, из приведённого тобою описания я очень смутно предлтавляю структуру твоего SMF.

Что есть "ядро системы"? Некий главный класс, от которого создаётся объект в единственном экземпляре?

Обработка этих данных = это задача модулей.
В конструкторе модуль-обработчик проверяет входящие параметры, если нужно, загружает валидатор, который выдает список/коды ошибок или возвращает отфильтрованные данные.

Получается все модули состоят из одних кострукторов?

Crazy · 30 Апр 2005

Автор оригинала: ONK
Это как мне может функция из глобальной области видимости заменить например объект пользовательской сессии или объект управления выводом, или объект абстрактного доступа к базе данных?

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

Кроме того, не надо путать существование глобальных переменных вообще и прямое манипулирование ими из прикладного кода.

К тому же засорение глобальной области видимости именами функций тоже плохая практика.

Без комментариев.

И ещё, как я понимаю предлагается вместо использования прямого доступа к параметрам конфигурационного массива применить вызов функции на подобии этого:

Ты понимаешь неправильно. Абсолютно незачем так лезть за каждым параметром. Достаточно взять объект Config и спрашивать у него.

так вот вызов этой функции в 10 - 15 раз медленнее прямого обращения к переменной.

И на сколько процентов это земедляет скрипт в целом? 1? 2?

-~{}~ 30.04.05 00:52:

Автор оригинала: Доктор
Люди рассуждают о том, что выпускать микроскопы не следует, так как некоторые могут ими начать забивать гвозди...

Не. Люди пытаются сказать, что фраза "микроскоп безусловно является необходимым средством для забивания гвоздей" -- неверна.

Доктор · 30 Апр 2005

Если и пытаются, то явно не выходит

Я, кстати, вижу только выпытывание аргументов за использование global, но от самих выпытывальщиков не вижу аргументов против этого.

Crazy · 30 Апр 2005

Автор оригинала: Доктор
Я, кстати, вижу только выпытывание аргументов за использование global

В порядке поступления заявлений.

Я никого за язык не тянул.

но от самих выпытывальщиков не вижу аргументов против этого.

Чтобы видеть -- нужно смотреть. Я не могу насильно вбить текст в глаза.

itprog · 30 Апр 2005

Crazy

Достаточно взять объект Config и спрашивать у него.

А как тогда взять этот объект Config ?

Crazy · 30 Апр 2005

Автор оригинала: itprog
А как тогда взять этот объект Config ?

Это действительно не очевидно? Ok. Показываю:

Код:

function & get_config() {
  static $config;
  if (!isset($config)) {
    $config = new Config('properties.txt');
  }
  return $config;
}

Screjet · 30 Апр 2005

приведённого тобою описания я очень смутно предлтавляю структуру твоего SMF.

Назначение описания исключительно для агрументации в пользу отсутствия глобалов.

neko · 30 Апр 2005

Автор оригинала: ONK
В пхп однако тоже есть static, причём он работает также как в Си.

да неужто?
хотелось бы про это услышать по подробнее
напоминаю, что мы говорили о глобальных переменных

betik · 30 Апр 2005

...Прикольная тема получилась...
Сторонники смерти global, можите ли привести аргумент в пользу вашей точки зрения, кроме "так удобнее/проще/легче", "запутаешься в коде"...
Или ссылочку дайте, только на русском...

ONK · 30 Апр 2005

Доктор, вам пора менять очки...

neko,

fixxxer
> Автоматический доступ к глобальным переменным изнутри функции, как это сделано в Си - да, было бы хуже.

в c однако есть static, это сильно упрощает процесс

ты бросил фразу, которая относительно контекста (использование global в функциях и методах) не имела никакого смысла. На что получил соответствующее замечание. И не надо пытаться говорить что ты имел в виду контекст файла, ты об этом даже не упомянул.

Crazy

Кроме того, не надо путать существование глобальных переменных вообще и прямое манипулирование ими из прикладного кода.

Стоп, я где либо говорил что глобальные переменные можно модифицировать из прикладного кода? Я считаю, что это не допустимо.

И на сколько процентов это земедляет скрипт в целом? 1? 2?

в ниже приведённом куске кода использование вызовов типа
$CONFIG->get(xx);
и
$Lang->get(yy);
По моим оценкам приведёт не менее чем к 2-х кратному снижению скорости работы цикла.

В некоторых случаях, где производительность наиболее важна приходится выносить из тела цикла и эти вызовы $oUser->get('time_d'), заменяя их на временные переменные.

PHP:

		while($row = $result->fetchRow()){
				/*
				вырезано лишнее
				*/
				$TPL->add(array(
				'~TPL198~'	=> $aLang['TPL198'],
				'~TPL249~'	=> $aLang['TPL249'],
				'~TPL250~'	=> $aLang['TPL250'],
				'~TPL251~'	=> $aLang['TPL251'],
				'~TPL291~'	=> $aLang['TPL291'],
				'~TPL119~'	=> $aLang['TPL119'],
				'"#FFFFFF"'		=> $CONFIG[90],
				'"#DDDDDD"'		=> $CONFIG[91],
				'~path~'		=> $path,
				'~text~'		=> $text,
				'~name~'	=> $name,
				'~html_auth_m~'	=> $row[2],
				'~url_auth_m~'	=> urlencode($row[2]),
				'~rel_time_m~'	=> relative_time($row[4]),
				'~date_m~'		=> gmdate($CONFIG[19].' '.$CONFIG[20],$row[4] + 3600 * $oUser->get('time_d')),
				'~rel_time_t~'	=> relative_time($row[5]),
				'~date_t~'		=> gmdate($CONFIG[19].' '.$CONFIG[20],$row[5] + 3600 * $oUser->get('time_d'))
				),21,$sp);
		}

Ты понимаешь неправильно. Абсолютно незачем так лезть за каждым параметром. Достаточно взять объект Config и спрашивать у него.

По производительности вызов функции даже чуть менее накладен чем вызов метода объекта.

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

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

А теперь код который ты просил:

PHP:

function data_process(){
	global $_POST; // пишу по привычке от работы с ZE
	echo $_POST['input_data'];
}
[php]

Ещё раз обозначу основные пункты своей позиции по данному вопросу.

1. Глобальные переменные нужны.
2. В качестве глобальных переменных должны использоваться сущности потенциально необходимые всем элементам скрипта, эти сущности глобальны по своей сути.
3. Глобальных переменных не должно быть много.
4. Глобальные переменные должны создаваться и модифицироваться только API ядра системы, другие элементы скриптов могут использовать глобальные переменные лишь как источник информации.

ООП : опрос + флуд

Developer

Новичок

Пассивист PHPСluba

Developer

Новичок

Пассивист PHPСluba

Новичок

Пассивист PHPСluba

Новичок

Новичок

Пассивист PHPСluba

Developer

Новичок

Developer

Cruftsman

Developer

Новичок

tеam neko

Новичок

Пассивист PHPСluba