Отрицание — самая предсказуемая человеческая реакция в случае, когда человек плохо разбирается в вопросе или используемые методики, обсуждаемых в вопросе, ему не привычны, да еще и кажутся «сложными».
Автор — молодец, предоставил многим материал для «размышления».
Сам я довольно часто вместо if'ов в JavaScript'e использую: a = a || 'defaultValue'; или! a && (a = 'defaultValue'); (последнюю конструкцию и в PHP юзаю) — это намного удобней, быстрей, и ни разу я не слышал от коллег, что это неудобочитаемо. И называть это «выпендрежем» — по меньшей мере голословно. При таком отрицающем подходе тогда, действительно, — незачем MVC, Pattern'ы проектирования, ООП в целом и т.д. Это все равно, что говорить (в JavaScript): var a = new Array(); — правильно, а var a = []; — уже выпендреж. Бред. =) Аналогию можно провести — есть математика уровня техникума, есть уровня университета. Так с какой стати мне писать на уровне математики 7 класса школы, чтобы код был понят каждым новичком после прочтения книги «PHP для чайников»?
Использую стиль «K&R» (который здесь назван «Рациональный»)
P.S.: Кстати, K&R стиль одним из названий имеет «Единственно верный способ постановки скобки» («The One True Brace Style», аббревиатуры 1TBS или OTBS) (название дано Деннисом Ричи)
> ну а замыкаемые переменные как значения, а не ссылки — это отдельный непередаваемый ппц
ну а с другой стороны — можно контролировать вручную — что по ссылке, а что нет (проводя аналогию с JS, опять же, — там ссылка на родительский скоп — и если вы меняете переменную родительского скопа после определения замыкания, то и замкнутая переменная будет указывать уже на новое значение, что с одной стороны хорошо, но не всегда; поэтому здесь (в PHP) сделали указание ссылки "&" вручную; хотя объекты «по ссылке» передаются)
упс =) пардон, перепутал с JavaScript'ом (просто в нем часто использую эту конструкцию). А перепутал на фоне того, что в PHP работает следующая конструкция:
!a && ($c = $b); // которую я также часто в JS и PHP юзаю вместо if (bla-bla) {...}
Хотя, с && и || можно сымитировать конструкцию из JS:
!$c && ($c = $b) || ($c = $a); // :D но выглядит это в сто раз хуже, чем полных тернарный оператор - поэтому - только посмеяться
если в замыкание попадут только нужные (перечисленные) данные из родительского скопа, то это еще лучше (в JavaScript, например (в текущей версии) - в замыкании оседает весь родительский скоп - независимо - 1 или 1000 свойств из родительского скопа вы используете во внутренней функции)
да что ж такое-то? =) опять не ту ссылку дал. Вот: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=javascript&lang2=python (здсь сравнение JS (реализация SpiderMonkey, не Rhino) и Python; там и с Руби можно сравнить):
вот здесь можно посмотреть (но за точность тестов я не ручаюсь, конечно). Если абстрактно - JavaScript уступает и Ruby, и Python'у, т.к. разрабатывался изначально для "небольших целей".
> ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
перфоманс относительно чего? Например, C++: JavaScript (нынешние реализации) медленней C++ в 50-200 раз (из-за интерпритируемости, динамического ООП на прототипах, тех же замыканий и анонимных функций, о которых тут идет речь).
ай-яй-яй.. Прошу меня извинить, я привел самый неудачный пример из всех, из которых можно было бы привести (с циклами; но это касается только JS, а не анонимных функций в целом).
Более подходящим примером может быть создание объекта по событию (по клику на кнопку, например) - и если там есть присвоение:
obj.onclick = function () {};
вместо:
obj.onclick = ранееОбъявленныйХэндлер;
то при первой реализации в случае 100 созданий, будет 100 функций (во втором одна).
Или же, возвращаясь к циклу - если подобная конструкция:
var test = {};
test[0] = {};
test[0].fn = function () {};
test[1] = {};
test[1].fn = function () {};
могла бы быть построена в цикле, то здесь видно четко, что функции созданы разные:
я, надеюсь, понятно, что мы утрировали и "не поменялось" касалось лишь количества - и там, и там - 100 объектов будет создано (в реале же разница - в первом случае 100 функций, во втором - 100 объектов, созданных на основе функции-конструктора Foo)
> что и требовалось доказать для фразы "ООП - зло"))
не понял, что вы имеете в виду (да и - касательно "ООП - зло" - я этого не говорил)
> Касательно анонимных функций и случая со 100 копиями функции.
> Если рассуждать логически
если логически - то все хорошо, но если заглянуть в спецификацию ECMAScript - то 100 функций.
> и скажите, что с точки зрения ресурсоемкости (точнее, ресурсопрожорливости) поменялось.
=) ничего не поменялось, посмотрите разделы "11.2.5 Function Expressions", "13. Function Definition", "15.3 Function Objects" спецификации ECMAScript-262-3
ахаха =) ну вот и все - переход на личности - верный (не первый, а верный) признак, что по существу, кроме дешевых провокаций и разглагольствований, больше сказать нечего.
Не "в таком случае", а "относительно" =) Любая высокая абстракция всегда несет за собой потери в ресурсах (ООП сюда тоже входит), но вряд ли это стоит приводить примером. В моем примере выше - всего лишь оптимизация в случае, если функция семантически одинакова для всех (ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов, чем одна).
Касательно ООП - динамическая модель, где есть только объекты и сообщения (первоначальная концепция Алана Кея (ООП из Smalltalk'a); "истинное ООП") - также, естественно, по ресурсам более затратно, чем ООП, основанное на классах, где нет возможности расширять динамически классы/объекты и инстансы классов/объектов. Но вместе с тем, оно более гибко, т.е., опять же, за более высокую абстракцию - платятся бОльшие ресурсы.
2AlexeyTokar, я понимаю, что незнание предмета заставляет вас яро кричать о том, в чем вы плохо разбираетесь, но минусы-то зачем лепить всем подряд? =)) Это уж явный признак дилетантизма.
Ну, первый абзац, простите, ни о чем (простая демагогия, придание воды).
> вместо присвоений
Принимается. Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
Однако, "захват нужного контекста" (а в этом патче и вообще, как я вижу, можно только определенный набор передавать в замыкание из родительского скопа; в JS - весь скоп родительский попадает), "незасорение глобального скопа", и т.д. в этих случае - вещь очень удобная.
> Вообще против ФП как парадигдмы я ничего не имею
Да я, вообще-то, тоже - ни против ФП, ни ИП. Я вправе использовать оба стиля. Меня просто всегда "умиляют" подобные ярые выкрики, основанные часто лишь на личных привычках и не более (надеюсь, что у вас не так =)
Автор — молодец, предоставил многим материал для «размышления».
Сам я довольно часто вместо if'ов в JavaScript'e использую: a = a || 'defaultValue'; или! a && (a = 'defaultValue'); (последнюю конструкцию и в PHP юзаю) — это намного удобней, быстрей, и ни разу я не слышал от коллег, что это неудобочитаемо. И называть это «выпендрежем» — по меньшей мере голословно. При таком отрицающем подходе тогда, действительно, — незачем MVC, Pattern'ы проектирования, ООП в целом и т.д. Это все равно, что говорить (в JavaScript): var a = new Array(); — правильно, а var a = []; — уже выпендреж. Бред. =) Аналогию можно провести — есть математика уровня техникума, есть уровня университета. Так с какой стати мне писать на уровне математики 7 класса школы, чтобы код был понят каждым новичком после прочтения книги «PHP для чайников»?
P.S.: Кстати, K&R стиль одним из названий имеет «Единственно верный способ постановки скобки» («The One True Brace Style», аббревиатуры 1TBS или OTBS) (название дано Деннисом Ричи)
ну а с другой стороны — можно контролировать вручную — что по ссылке, а что нет (проводя аналогию с JS, опять же, — там ссылка на родительский скоп — и если вы меняете переменную родительского скопа после определения замыкания, то и замкнутая переменная будет указывать уже на новое значение, что с одной стороны хорошо, но не всегда; поэтому здесь (в PHP) сделали указание ссылки "&" вручную; хотя объекты «по ссылке» передаются)
!a && ($c = $b); // которую я также часто в JS и PHP юзаю вместо if (bla-bla) {...}
Хотя, с && и || можно сымитировать конструкцию из JS:
!$c && ($c = $b) || ($c = $a); // :D но выглядит это в сто раз хуже, чем полных тернарный оператор - поэтому - только посмеяться
Поэтому все-таки $c = $a ?: $b;
$c = $a || $b;
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=javascript&lang2=python
> Когда сделают 4 версию с
а про ES4 (JS2) никто и не говорит =) вполне может быть, что не только "куда более", а "очень куда более"
перфоманс относительно чего? Например, C++: JavaScript (нынешние реализации) медленней C++ в 50-200 раз (из-за интерпритируемости, динамического ООП на прототипах, тех же замыканий и анонимных функций, о которых тут идет речь).
Более подходящим примером может быть создание объекта по событию (по клику на кнопку, например) - и если там есть присвоение:
obj.onclick = function () {};
вместо:
obj.onclick = ранееОбъявленныйХэндлер;
то при первой реализации в случае 100 созданий, будет 100 функций (во втором одна).
Или же, возвращаясь к циклу - если подобная конструкция:
var test = {};
test[0] = {};
test[0].fn = function () {};
test[1] = {};
test[1].fn = function () {};
могла бы быть построена в цикле, то здесь видно четко, что функции созданы разные:
alert(test[0].fn === test[1].fn);
я, надеюсь, понятно, что мы утрировали и "не поменялось" касалось лишь количества - и там, и там - 100 объектов будет создано (в реале же разница - в первом случае 100 функций, во втором - 100 объектов, созданных на основе функции-конструктора Foo)
> что и требовалось доказать для фразы "ООП - зло"))
не понял, что вы имеете в виду (да и - касательно "ООП - зло" - я этого не говорил)
> Касательно анонимных функций и случая со 100 копиями функции.
> Если рассуждать логически
если логически - то все хорошо, но если заглянуть в спецификацию ECMAScript - то 100 функций.
=) ничего не поменялось, посмотрите разделы "11.2.5 Function Expressions", "13. Function Definition", "15.3 Function Objects" спецификации ECMAScript-262-3
> А вот тут вы заблуждаетесь ;-)
неа =) но все же спрошу - а где? =)
Я с вами еще вчера разговор закончил.
Демагогия и глупая подмена понятий, не более. Речь в примере не о ФП, а лишь об анонимной функции.
Еще раз, человек, если вы не понимаете что-то, то это не значит, что это плохо.
P.S.: небось руки уже снова чешутся кнопочку "минус" всем нажать? =))
Не "в таком случае", а "относительно" =) Любая высокая абстракция всегда несет за собой потери в ресурсах (ООП сюда тоже входит), но вряд ли это стоит приводить примером. В моем примере выше - всего лишь оптимизация в случае, если функция семантически одинакова для всех (ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов, чем одна).
Касательно ООП - динамическая модель, где есть только объекты и сообщения (первоначальная концепция Алана Кея (ООП из Smalltalk'a); "истинное ООП") - также, естественно, по ресурсам более затратно, чем ООП, основанное на классах, где нет возможности расширять динамически классы/объекты и инстансы классов/объектов. Но вместе с тем, оно более гибко, т.е., опять же, за более высокую абстракцию - платятся бОльшие ресурсы.
1. ссылка всегда на одну функцию
объект.fn = function () {alert(1);};
for (var k = 0; k < 100; k++) {
blaBla = объект.fn;
}
2. тот же случай, но 100 разных "одинаковых" функций:
for (var k = 0; k < 100; k++) {
blaBla = function () {alert(1);};
}
На этом, собственно, 5% "зла" анонимных функций, о которых я отмечал человеку, ставящему всем минусы, заканчиваются.
2AlexeyTokar, я понимаю, что незнание предмета заставляет вас яро кричать о том, в чем вы плохо разбираетесь, но минусы-то зачем лепить всем подряд? =)) Это уж явный признак дилетантизма.
Для себя я разговор закончил.
> вместо присвоений
Принимается. Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
Однако, "захват нужного контекста" (а в этом патче и вообще, как я вижу, можно только определенный набор передавать в замыкание из родительского скопа; в JS - весь скоп родительский попадает), "незасорение глобального скопа", и т.д. в этих случае - вещь очень удобная.
> Вообще против ФП как парадигдмы я ничего не имею
Да я, вообще-то, тоже - ни против ФП, ни ИП. Я вправе использовать оба стиля. Меня просто всегда "умиляют" подобные ярые выкрики, основанные часто лишь на личных привычках и не более (надеюсь, что у вас не так =)