Магический метод __get в статическом классе

alexeyco

Новичок
Магический метод __get в статическом классе

Добрый день!

Такая тема.. к примеру, есть класс

PHP:
<?php

/**
 * Class for working with config array
 */

class Config {

  /**
   * Config array
   * @var array
   */
  private static $_config = array();

  /**
   * Loaded files
   * @var array
   */
  private static $_loadedFiles = array();

  /**
   * Loaded domains
   * @var array
   */
  private static $_loadedDomains = array();

  /**
   * Load new config file
   * @param string $file
   * @return self
   */

  public static function loadFile($file) {

    if (!in_array($file, self::$_loadedFiles)) {

      require_once DIRECTORY_CONFIG . $file . '.' . PHP_EXT;

      self::$_loadedFiles[] = $file;
      self::$_config = array_merge(self::$_config, $config);

    }

  } // loadFile();

  /**
   * Loads the config of a domain
   * @param string $domain
   * @return self
   */

  public static function loadDomainConfig($domain) {

    if (!in_array($domain, self::$_loadedDomains)) {

    }

    return self;

  } // loadDomainConfig();

  /**
   * Returns the value of a config index
   * @static
   * @param string $index
   * @return string
   */

  public function __get($index) {

    return (isset(self::$_config[$index])) ? self::$_config[$index] : null;

  } // __get();

} // Config

?>
Тогда при следующей конструкции типа:
PHP:
Config::loadFile('db');
В него должен подгрузиться некий файлик.... НО при обращении к некоторому значению конфига типа
PHP:
echo Config::$db_type;
Происходит ошибка типа Fatal error: Access to undeclared static property: Config::$db_type

-~{}~ 24.02.10 18:27:

А... пардон - ну и соответственно вопрос... Что делать? Я пытался погуглить но так и не понял - это баг или фича?
 

Adelf

Administrator
Команда форума
alexeyco
у тебя прекрасно получается :) Продолжай в том же духе :)
 

AmdY

Пью пиво
Команда форума
учитывая то, что у тебя вызов переменной зависит от загрузки конфига, так статику применять нельзя. можно
Config::loadFile('db')->db_type - реализовав singlton, или смесь singleton-registry
 

alexeyco

Новичок
Или сделать публичный статичный параметр (array)$data
Config::data['some_parameter']; и не парить мозг...

Adelf
Я не понял это сарказм или что?
 

Adelf

Administrator
Команда форума
alexeyco
Сарказм.

Config::get('some_par') - тоже подойдет.

З.Ы. Просто я статиками уже переболел, вот и юморю...
 

AmdY

Пью пиво
Команда форума
правильно был сарказм,
Config::data['some_parameter'] и Config::get('some_par') - они не гарантируют, что нужный конфиг уже был подгружен. в Config::get('some_par') можно хотя реализовать ленивую подгрузку конфига.
 

alexeyco

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

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

Кстати, я сейчас смотрю что я проделал - я переписал шаблонизатор, слои для БД и прочую всю шелупонь, которая должна быть доступна "из воздуха", а так же рассовал "повседневные" функции по статичным классам и теперь не могу остановиться...

Пока сам не бенчил - но расскажите... объективно, помимо магических методов - когда надо использовать НЕ статические классы?

-~{}~ 26.02.10 02:32:

ЗЫ
Про "парить" - я просто просил не обсуждать возможность использования геттекстов всяких...
 

Adelf

Administrator
Команда форума
alexeyco
переписываешь ради результатов бенчей?
А есть объективная причина у тебя так делать(например проект который тормозит именно из-за того, что некоторые классы не статические)?


З.Ы. Не нарисовал ни одного смайла. Получился суровый программерский вопрос :)

-~{}~ 26.02.10 02:48:

>> Про "парить" - я просто просил не обсуждать возможность использования геттекстов всяких...

Ну парить - не парить, но таскать из базы языковые данные - это довольно странно. Они у тебя какие-то особенные что ли? Слишком часто меняются?
 

alexeyco

Новичок
Ну они МОГУТ меняться, да... ну и конечно же они кешируются - и класс кешер, который способен работать и с мемкешедами, и с фс - уже тоже статичный.

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

Дальше что я сделал... дальше я переписал класс шаблонизации - оказалось, что это еще и сокращает код... ну то есть меня конечно не ломает лишних символов писать... но тем не менее.

И теперь я реально смотрю на то, что у меня получается - и только пожалуй в двух местах мне понадобится использовать инстанцирование объектов. В остальных у меня ПОКА тоже динамические классы, но я уже примеряюсь и к ним.

Ведь возьмем тот же самый друпал - в принципе, довольно распространенный продукт, не сильно-то и блещущий ООП как таковым, не то что другое чего (опустим здесь его удобство и прочие). Я имею в виду, что разработчики уж точно способны потратить ресурс на изменение архитектуры под ООП, однако ж нет - они выбрали для себя направление и идут.

Так вот вопрос - до какого разумного предела в этом можно дойти? Ведь если имеет право на существование абсолютно не объектный подход, имеет право и подход "статические классы во все щели"? Тем более, что так мы практически все преимущества ООП тоже имеем.
 

Adelf

Administrator
Команда форума
Так вот вопрос - до какого разумного предела в этом можно дойти? Ведь если имеет право на существование абсолютно не объектный подход, имеет право и подход "статические классы во все щели"? Тем более, что так мы практически все преимущества ООП тоже имеем.
Статический класс - это фактически модуль, в понимании таких языков как Pascal например :) Да и любого языка поддерживающего функции и возможность include какого нибудь.
Это набор функций, и глобальных переменных, ну разве что с нэймспейсом, роль которого играет имя класса.
Писать так действительно можно. И много хорошего в прошлом веке было написано именно с таким подходом. Но затем придумали таки ООП :) И не зря.

-~{}~ 26.02.10 03:33:

Ты так и не ответил на вопрос про бенчи.
Если это - причина, то дальше разговаривать не о чем :) Такие серьезные правки в архитектуре должны быть из-за более объективных причин.
 

Fortop

Новичок
но расскажите... объективно, помимо магических методов - когда надо использовать НЕ статические классы?
Всегда, когда нужны.

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

Тем более, что так мы практически все преимущества ООП тоже имеем.
Например? Какие?

Если я захочу для вот этой фигульки сменить бекенд кеша? Чего мне делать с статическим классом кеширования?

А если я хочу иметь вложенные шаблоны? Извращаться и реализовывать стек внутри шаблонизатора?

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

alexeyco

Новичок
Так товарищи, вы не нападайте! Я задал вопрос а не утверждал.

Во-первых, статичные классы разве не являются ООП? ))) Эгегей )))) Но это не так важно.

Вот я и спрашиваю - каким мне образом поступить? Я например нашел аналогию в мире прекрасного на свой же вопрос.

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

Я вообще, несколько лет назад именно таким проектом - с наследованным исходным кодом и занимался... и в общем то о нем и идет здесь речь. Потому - приведите пжл примеры открытых проектов с офигенным подходом в ООП... но я имею в виду не фреймворков, а работающих систем - к примеру, как оскоммерц. Попробую проанализировать "как там".

-~{}~ 26.02.10 11:03:

И да - я-таки бенчмаркал... выигрыш получался (если брать во внимание класс БД) существенным... если приходилось делать несколько тысяч запросов. Но если в относительных величинах - до 5% экономия оперативы в различных ситуациях. Я имею в виду не от всего проекта, а конкретно от того, что объект не замусоривал оперативу.
 

Adelf

Administrator
Команда форума
alexeyco
Скажу тебе как уже падавший в эти канавы - забей на бенчмарки до тех пор пока у тебя не начнет что-то конкретно тормозить.

Что такое статический класс, я тебе уже сказал. Это модуль времен лихих 80-х :) ну разве что с неймспейсом.

Возьми любую ORM. Возьми нормальный свеженький php-фреймворк, который для пятого php писался. Примеров много.
 

alexeyco

Новичок
Adelf
Да ну что ж вы какие сами закостенелые то ))))
Ладно - буду кавиряться дальше... просто раньше я все пытался-пытался.. ну ладно - все это полемика... я чем люблю кодинг - тем, что там нельзя быть неправым )))) как только ты становишься неправ - ты меняешь свое мнение, меняешь подход и ты снова прав... Скажу как человек, попадавший в РАЗНЫЕ канавы - важно выбрать наиболее оптимальный подход в любом вопросе. Не важно, какого года решение. Один из законов Мерфи гласит: если это глупо, но работает хорошо, значит это не глупо.

HraKK
Улыбнуло по ссылке:
Конечно, это не относится не ко всем классам
Согласно логике, можно отрицание вынести за скобки и написать
Конечно, это не (относится ко всем классам)
:)
 

HraKK

Мудак
Команда форума
нельзя. имелось ввиду когда законченая final библеотечка, тоо можно и статически. А фреймворк и проект не бывают final.

-~{}~ 26.02.10 12:59:

до 5% экономия оперативы
акуеть. не 1 мб, а 950 кб!!!!11
При том что сейчас везде гигабайты памяти, пыщь, пыщь, ололо, риале!
 

alexeyco

Новичок
Имхо, аргумент не взрослого человека... да и способ подачи аргумента тоже. Когда есть два равнозначных пути, а мы выбираем менее выгодный, но более понравившийся и общепринятый - это не подход серьезного человека ИМХО. Так и становятся стадом. Жалко нельзя никуда минусануть.
 

HraKK

Мудак
Команда форума
Какие они в попу равнозначные. Равнозначные для нубов, которые не понимают ни первого ни второго. Именно, поэтому и нельзя минусовать.

Задрали своим стадом. Самое интересное, что чем больше человек относиться к стаду тем больше он кричит что он не стадо, а все вокруг ололо стадО!
 
Сверху