Меню
Что нового?

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

Crazy

Crazy

Developer
ONK, ты стараешься напрасно:

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

ONK

Пассивист PHPСluba
lovchy, Вообще-то переписать в ПХП нельзя только константу, все переменные переписать можно. Ты возможно имел в виду реинициализацию тем же объектом, а такая ошибка на порядок более редкая чем присвоение произвольного значения.

Либо незнание эффективных альтернативных способов. Если ты не видишь решений -- это ещё не значит, что их нет.
Нажмите для раскрытия...
Не надо пустых фраз. Как только ты меняешь массив на объект и используешь для получения данных методы, ты получаешь 15 кратное замедление выполнения этой операции. Да, можно напрямую обращаться к внутренним свойствам объекта, в этом случае будет всго 2-х кратное падение скорости выполнения операции, но это нарушение принципов ООП.

А людям свойственно ошибаться (опечатки, недосмотры, ...). Почему бы не предусмотреть всё это программно?
Нажмите для раскрытия...
С этим никто не спорит. Если бы это было можно сделать с такой же надёжностью и эффективность как в С++ я был бы обеими руками ЗА.

Кому? Известны тебе, не известны другим. К тому же, если можно программно запретить себе сделать ошибку, -- лучше запретить, а не пологаться на свою память и свой интеллект. Слишком часто они людей подводят.
Нажмите для раскрытия...
Если кто-то хочет что-то интегрировать для работы в твой продукт, ему придётся прочитать соответствующую документацию по работе с API. А знать внутренние алгоритмы работы API с глобальными переменными для подобного пользователям совершенно ненужно.

Запретить же сделать ошибку перезаписи переменной, как я уже выше написал, в ПХП нельзя.
 
valyala

valyala

Новичок
Код: 
$i=100;

function bred()
{
echo $i;
}

bred();
Автор оригинала: SiMM
> Если бы этот кусок кода выводил бы "100", то это было бы плохо.
"в языке, не требующем явного объявления переменных" это было бы по крайней мере нелогичным.
Нажмите для раскрытия...
SiMM, скажи это по крайне мере Larry Wall'у и Brendan Eich'у.
Код на perl:
Код: 
my $i = 100;
sub bred { print $i; }
bred();
Код на javascript:
Код: 
i = 100;
function bred() { alert(i); }
bred();
 
lovchy

lovchy

nacido para cifrar
ONK
Ну ка покажи мне как можно извне, не выдрачиваясь, переписать статическую переменную метода. Прежде чем умничать, вникнись в суть написанного.

> Как только ты меняешь массив на объект и используешь для получения данных методы, ты получаешь 15 кратное замедление выполнения этой операции.

Любимый аргумент тех, кому уже нечего сказать против подхода. Если я работаю с PHP, я выбираю удобство. И если вместо 1 наносекунды я получу 15 (откуда цифра 15? Тесты в студию), я этого даже не замечу. Зато я сделаю меньше ошибок и мне приятнее будет работать с кодом. Внимание, вопрос: не составляет ли у тебя 90% кода -- расширения на C? Нет? А почему? Оно ведь быстрее.

> Если кто-то хочет что-то интегрировать для работы в твой продукт, ему придётся прочитать соответствующую документацию по работе с API. А знать внутренние алгоритмы работы API с глобальными переменными для подобного пользователям совершенно ненужно.

Ну конечно. Про классы читать надо, а о существовании глобальных переменных разработчики сами догадаются. Телепатия-с? Да и сделать Foo::getInstance, разумеется, неимоверно труднее чем сделать global $foo. Это при том, что Foo::$Instance не перезапишется никак, хоть ты тресни, а $foo вполне можно переписать по ошибке (и дальше смотри аргументы Crazy). Больше того, Foo::getInstance полностью удовлетворяет идее инкапсуляции. Вообще, следуя твоей логике, можно сказать, что модификаторы доступа к элементам -- тоже лажа. Полюбому будут тормозить.

И вообще, что за однобокий взгляд на проблему? Одна система, одни пользователи, один API. Меня не покидает ощущение, что ты всё это говоришь в рамках одного, возможно крупного, проекта, разработкой которого ты занимаешься.
 

ONK

Пассивист PHPСluba
Странно, некоторым людям кажется, что стараются персонально для них. Я же выражал свою точку зрения для всей общественности. Думаю, что эта тема была достаточно интересной многим.

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

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

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

Однако при интеграции двух независимо разработанных программных продуктов с не меньшей вероятностью могут возникнуть конфликты, связанные с проблемой засорения глобальной области видимости имён функций (я не случайно упомянул об этом ранее). Причём вероятность конфликта имён переменных типа $CONFIG приблизительно такая же, как и вероятность конфликта имён функций get_config(), get_lang().... или имён аналогичных классов. Все эти конфликты требуют вмешательства в код движка одного из продуктов (или в оба программных продукта).

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

Подвожу небольшой итог:

Если бы в ПХП классы (объекты) работали бы также эффективно как в С++ я бы для доступа к основным сущностям использовал бы именно их (в тандеме с синглтон паттерном). А при текущем положении вещей (которое собственно никогда и не изменится по природе языка ПХП), по совокупности выше обсуждённых плюсов и минусов я предпочитаю использовать в качестве основных сущностей глобальные переменные.

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

lovchy

nacido para cifrar
> Если бы в ПХП классы (объекты) работали бы также эффективно как в С++

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

Что касается проблемы конфликта -- её разрешают неймспейсы. Она не имеет никакого отношения к обсуждаемому.

Об аксиомах же никто не говорил. Crazy привёл два аргумента. Ты их видел?
 

ONK

Пассивист PHPСluba
lovchy, давай ты немного изменишь общий тон, я же ведь не кусаюсь, и не гавкаю. ок? :)

Ну ка покажи мне как можно извне, не выдрачиваясь, переписать статическую переменную метода. Прежде чем умничать, вникнись в суть написанного.
Нажмите для раскрытия...
Я видел несколько реализаций паттрена синглтон, в тех что я видел, при вызове конструктора объекта возвращалась ссылка на ранее созданный экземпляр (если он не был создан, то он создаётся). Вскользь замечу про извращённую реализацию этого паттерна на ПХП. Если мы придерживаемся этого принципа, то мы всегда имеем возможность записать в переменную содержащую объект всё что хотим. Если же ты собрался возвращать из конструктора копию, то для некоторых сущностей это неприемлемо (размер конфигурационного объекта и объекта многоязыкового интерфейса слишком большие чтобы их копировать в каждую функцию, где они могут понадобиться).

Внимание, вопрос: не составляет ли у тебя 90% кода -- расширения на C? Нет? А почему? Оно ведь быстрее.
Нажмите для раскрытия...
Думаю что составляет, во всяком случае где-то близко. Хотя это и стандартные расширения ПХП.

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

Любимый аргумент тех, кому уже нечего сказать против подхода. Если я работаю с PHP, я выбираю удобство. И если вместо 1 наносекунды я получу 15 (откуда цифра 15? Тесты в студию), я этого даже не замечу.
Нажмите для раскрытия...
1. Всё что я хотел сказать против подхода я сказал выше, ничего другого против него я не имею.
2. Если ты всётаки прочитаешь одно из моих сообщений, ты найдёшь кусок цикла из реального кода. Если переделать этот кусок на использование объектов Lang и Config он будет работать ~ в 12 раз медленнее. В целом скрипт, в котором этот цикл находиться будет работать по моим оценкам в 2,5 раза медленнее (или в 6 - 7 раз медленнее при использовании средств кэширования опкода). Ты можешь не доверять моим оценкам, это твоё право, однако я бы к ним отнёсся как к ценной информации.

Вот тест, который ты просил. Я немного ошибся, разница составляет не 15 а ~ 20 раз. :)
PHP: 
<?php
class Time_mark{
	var $s_m;

	function Time_mark(){
		$this->s_m = explode(" ",microtime());
	}

	function current_time(){
		$prom = explode(" ",microtime());
		return $prom[1] + $prom[0] - $this->s_m[1] - $this->s_m[0];
	}
}

$lang = array('werysdfh','wagfdsfg','hsrty','asdfgdsf','asdg');

function get_lang($index){
	static $lang = array('werysdfh','wagfdsfg','hsrty','asdfgdsf','asdg');
	return $lang[$index];
}

class Lang{

	function Lang(){
		$this->lang = array('werysdfh','wagfdsfg','hsrty','asdfgdsf','asdg');
	}

	function get_lang($index){
		return $this->lang[$index];
	}
}

$a = '';

$items = 10000;

$oTimer = new Time_mark();

for($i = 0;$i < $items;$i++){
	$a = $items%4;
}

echo $calibr = $oTimer->current_time(),'<hr>';


$oTimer = new Time_mark();

for($i = 0;$i < $items;$i++){
	$a = $lang[$items%4];
}

echo $oTimer->current_time() - $calibr,'<hr>';

$oTimer = new Time_mark();

for($i = 0;$i < $items;$i++){
	$a = get_lang($items%4);
}

echo $oTimer->current_time() - $calibr,'<hr>';

$oLang = new Lang();

$oTimer = new Time_mark();

for($i = 0;$i < $items;$i++){
	$a = $oLang->get_lang($items%4);
}

echo $oTimer->current_time() - $calibr,'<hr>';

$oLang = new Lang();

$oTimer = new Time_mark();

for($i = 0;$i < $items;$i++){
	$a = $oLang->lang[$items%4];
}

echo $oTimer->current_time() - $calibr,'<hr>';

?>
-~{}~ 05.05.05 17:49:

Crazy привёл два аргумента. Ты их видел?
Нажмите для раскрытия...
А ты читал вообще то, что я написал?

-~{}~ 05.05.05 17:56:

lovchy,
Надоело пустословие о тормозах ООП Я вот склонен полагать, основываясь на свою практику, что ты заблуждаешься.
Нажмите для раскрытия...
ООП тут непричём, в ПХП накладен вызов функций. А ООП надо просто уметь использовать, но это приходит с практикой. :)
 
lovchy

lovchy

nacido para cifrar
ONK
По поводу тона ты прав, извини. Сказывается общее состояние. Постараюсь больше не грубить.

Касательно синглтона -- да, разумеется возвращается копия. И я говорил о PHP5, в котором, как ты знаешь, все объекты адресуются ссылками. Соответственно, уже нет нужды возврщать референс на внутреннюю статическую переменную.

> Хотя это и стандартные расширения ПХП.

Стандартные расширения языка -- это реализация итератора. Я говорю о твоём продукте.

> Прочитай пожалуйста то, что я писал ранее по этому поводу.

Читал, понял точно так же, как и раньше. Реформулируй.

Тест прочитал -- занимательно. Никакого отношения к сути спора не имеет. Тест не имеет права на жизнь. Наш ответ чемберлену:

PHP: 
<?php

class Time_mark{
    var $s_m;

    function Time_mark(){
        $this->s_m = explode(" ",microtime());
    }

    function current_time(){
        $prom = explode(" ",microtime());
        return $prom[1] + $prom[0] - $this->s_m[1] - $this->s_m[0];
    }
}

// ----

// Rabbit
class Foo
{
    static $Instance = null;

    static public function getInstance()
    {
        if ( is_null(self::$Instance) )
        {
            self::$Instance = new self;
        }

        return self::$Instance;
    }

    public function meow()
    {
    }
}

// ----

// Global var
$foo = new foo;
// ----

// Function-resolver
function get_foo()
{
    static $instance = false;

    if ( !$instance )
    {
        $instance = Foo::getInstance();
    }

    return $instance;
}


// ----------------- Test Area

function testGlobals()
{
    global $foo;

    $foo->meow();
}

function testFuncs()
{
    $bar = get_foo();

    $bar->meow();
}

function testClass()
{
    $bar = Foo::getInstance();

    $bar->meow();
}

// ------

$iters = 10000;

// - globals -

$timer = new Time_mark();

for($i = 0;$i < $iters;$i++){
    testGlobals();
}

echo $calibr = $timer->current_time(),"\n";

// - funcs -

$timer = new Time_mark();

for($i = 0;$i < $iters;$i++){
    testFuncs();
}

echo $timer->current_time() - $calibr,"\n";

// - class -

$timer = new Time_mark();

for($i = 0;$i < $iters;$i++){
    testClass();
}

echo $timer->current_time() - $calibr,"\n";

?>
Как наглядно видно из _правильного_ теста, тормоза связанные с использованием синглтонов -- заблуждение.

-~{}~ 05.05.05 18:25:

> А ты читал вообще то, что я написал?

Я читал. Кроме скорости ни одного аргумента. И ты не опроверг его утверждения. Ты не ответил на вопрос: ты читал, что он написал?
 
itprog

itprog

Cruftsman
<?php
$var[1] = "user";
$var[2] = "name";
function check($var)
{
global $$var[1][$var[2]];
echo $$var[1][$var[2]];
}
check($var);
?>

И пхп умер от глобала:)
 

ONK

Пассивист PHPСluba
lovchy, объясни, что ты тестируешь и как это связанно с этим:

Как только ты меняешь массив на объект и используешь для получения данных методы, ты получаешь 15 кратное замедление выполнения этой операции. Да, можно напрямую обращаться к внутренним свойствам объекта, в этом случае будет всего 2-х кратное падение скорости выполнения операции, но это нарушение принципов ООП.

(это тот пункт, который вызвал твоё недоверие, и ты попросил меня написать для тебя тесты). Тот тест, что ты привёл хоть и показывает почти 2- х кратную потерю производительности при использовании синглтонов вместо глобальных объектов, но он совершенно никак не связан с этим пунктом.

И ещё, весь код что я пишу я пишу так, чтобы он одинаково работал и в ПХП4 и в ПХП5. Твоя реализация синглтон паттерна в ПХП 4 работать не будет. Всё что можно реализовать для ПХП 4 будет реализовано через передачу объекта по ссылке (которая не будет скопирована в случае операции модификации), а в этом случае синглтон ничем не лучше глобальной переменной.

-~{}~ 05.05.05 19:14:

itprog
Забавно, :)
у тебя не валидная конструкция global $$var[1][$var[2]];

Должен быть парс еррор. Создавай багрепорт в http://bugs.php.net/
 
itprog

itprog

Cruftsman
То что код не валиден я сам понимаю. Глобалс - оружие хакеров. :)
Этот код убивает php5.0.4 и php4.3.11
 
lovchy

lovchy

nacido para cifrar
ONK
Да. Совершенно верно. Не будет. Я пишу только для PHP5.

Мой тест -- пример замены использования глобалов на синглтон или функцию. Валидный пример: все варианты исполняются в своём пространстве. Он показывает, что синглтон незначительно уступает глобалам, а это противоречит твоему аргументу.
 

ONK

Пассивист PHPСluba
lovchy, какому моему аргументу это противоречит? Ты потерял нить дискуссии и уходиш в настоящий флейм.

Я привёл для тебя цитату из моего сообщения, чтобы ты не утруждался, но ты всёравно пытаешся подменить сущность моего утверждения. Не получится. ;)

itprog, пиши багрепорт, такого не должно быть.
 

Frol

Новичок
дрючили OOP, надоело, перестали.
начали дрючить global, надоело, перестали.
дрючат скорость OOP, уже надоедает.
что следующее?
 
lovchy

lovchy

nacido para cifrar
Frol
Какие у тебя проблемы то? Мы в оффтопике, правил не нарушаем. Отвянь.

ONK
Это твой тест, как раз, не соответствует нити.
 
Войдите или зарегистрируйтесь для ответа.
Сверху