можно узнать почему?

Он есть много ресурсов. И его всегда можно заменить.
У меня принцип не пользоваться некоторыми функциями и конструкциями, в их числе with и eval

Это сообщение отредактировал(а) Aliance - 17.12.2006, 17:44

Aliance, 

Объясните подробней, что нужно с текстом сделать (а то до меня обычно долго "доходит"), но уж если "дойдет", то постараюсь обязательно. Интересно, знаете ли, стало, что за проблема...

В коде, который я использую сечас нет интерактирности, т.е. слова "показать" и "скрыть" - статичны. Динамичными их не сделать, т.к. в стандартных функциях IPB в добавляемом ббкоде есть синтаксис вида [tag=option]content[/tag], где я могу обратиться к option и content. content - это текст скрываемый, а если поставить в option что-либо, то это помжно было бы передавать 2 аргументом моей функции show_hide_text и далее парсить, разбивать или брать поэлементно из массива. Но саму надпись изначально поменять нельяз, т.к. в движке IPB нельзя написать что-то вроде {$options[0]}

Кому как, а мне не нравится т.к.:

- создание нового объекта в scope chain не адекватно задаче сокращения кода/обращений к чему-либо;
- интерпретатору сложнее работать;
- баги сложнее отлавливать;
- сложнее читать (ньюбам особенно, WithStatement - не такая простая вещь, как кажется);

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

Не так уж много он и ест, а код становится читабельнее.


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

Добавлено @ 18:33 


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

Таких ситуаций нет. Спорить по этому поводу - в другой теме.

Собрал несколько ссылок по теме. Если по прочтении кто-то всё-таки решит(ся) поспорить - откройте ветку, чтобы тут не мешать.

Тема началась отсюда, продолжение дискуссии держим здесь.

P.S. with не медленный на самом деле, это мифы древнего глючного нетскейповского кода. Но мне кажется такой код менее читабельным.

Aliance, спорить не хочу, но хочу привести пример (если нужно, можешь перенести в другую тему, создавать не буду ради одного поста). Использовать/не использовать "with" в некоторых случаях решать программисту, т.е. вам.

test1() - без использования with
test2() - с использованием with вне цикла
test3() - с использованием with внутри цикла
Плюсом объект o:
a. получает ссылку на объект DOM
b. (закоменчена) создается новый объект вне DOM дерева. Для этого случая количество итераций повышалось для точности, потому как скорость гораздо выше.

Результаты (прогонялись по несколько раз):
IE 6: a=2922,2328,2609; b=656,600,550
FF 2: a=3200,2422,2829; b=281,580,1530
OP 9: a=1250,1250,1220; b=296,375,453
NS 8: a=3350,2450,3090; b=250,547,2550
MZ 1.7: a=2950,2180,2750; b=250,610,1960

Как видим, для обоих случаев в скорости работы отличился только IE, остальные браузеры с объектами не DOM дерева работают быстрее без with - имеет смысл оператор здесь не использовать совсем. Для первого же случая, когда мы обращаемся к свойствам элемента страницы, синтаксис в внешним по отношению к циклу with выигрывает в скорости (хотя девятой Опере это по барабану, со JS она всегда работала на ура).
Этим тестом я не хочу доказать, что я прав в стремлении использовать оператор with в случаях, когда код становится более читабельным (для меня), но при этом не теряется скорость выполнения алгоритмов при грамотном написанном коде. Конечно, JS это скрипт, а не компилируемый язык, отсюда и сложность работы интерпретатора, и замедление в тесте b. Плюсуем комментарии умных людей, которые вы привели в соседней теме, и делаем вывод, что использовать его есть зло. Но радужные обещания нескольких известных всем компаний по поводу того, что в скором, возможно, появится "полноценный компилятор" для этого языка, который увеличит быстродействие на порядок, лично меня убеждает в том, что with-оператор не отменят и его использование будет оправданным.

P.S. дабы не показаться тупо голословным новичком в JS, приведу некоторые из своих работ:
http://dhtml-menu.com/tree-examples/tree-menuxp.htm
http://deluxe-menu.com/
http://dhtml-menu.com/dhtml-tab-menu/tab-menu-mac.html
http://dhtml-menu.com/dhtml-tabs/
(за работу самих сайтов прошу заранее извинить, ибо их поддержку завершил год назад)

Добавлено @ 22:08 
пардон за начало поста, изначально писал для прошлой темы, где нельзя было спорить   

Не боись, ты таким не кажешься. Наоборот. 


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


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

Что касается теста, то он некорректный, т.к. в test1 закеширован document.getElementById('ddd') , а надо бы document.getElementById('ddd').style. Лишняя прогулка. Это сразу выводит первый тест на первое же место. У меня (на загруженной системе):


http://www.404.googlepages.com/test_with_s...ment_speed.html

p.s. Хотя имхо скорость тут - последний минус в ряду минусов. 

С этим согласен, хотя обычно ситуации не такие - часто приходится получать ссылку на объект, а уже потом уже пользовать оператором with при проходе, например, по этому же полю .style. Здесь же получается, что мы создаем ссылку на поле (на свойство) объекта без возможности получить отсюда в дальнейшем ссылку на сам объект. Конечно, можно ввести доп. переменную...

Добавлено @ 00:50 
P.S. with пришел ко мне еще со времен ранних версий Delphi, поэтому отказаться от него в некоторых ситуациях сложновато   

Там даже знаешь чего..., надо бы в третьем тесте для чистоты заменить with (o.style) на with (o) , a в переменную o положить тоже style, как в первом тесте (у меня). Тогда третий тест в некоторой степени по lookup сравняется с первым, при каждом проходе будем сначала вычислять сам o, а потом его свойства. И третий тест ускорится (может и сравняется с первым).

А во втором можно оставить всё как есть, объект вычисляется один раз, а уже потом крутятся циклы, но тут есть побочный эффект в виде идентификатора  i, который сначала вычисляется в контексте o.style, видимо это и замедляет работу.


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


http://www.404.googlepages.com/test_with_s...nt_speed_2.html

Это сообщение отредактировал(а) Zeroglif - 18.12.2006, 01:21

Zeroglif, вообще, было бы времени свободного чуть больше, можно было бы сделать тест из какой-нибудь реальной задачи (благо код есть в наличии). Может быть попробовать ради чистоты эксперимента вынести набор операций в функцию, чтобы идентификатор i не был в контексте объекта.

Вот, решил поделиться впечатлением от прочитанного из ссылок по этой теме. В общем и целом впечатление одно, и его можно выразить цитируя человека по имени Brendan Eich. 
В одном из форумов предварительно было выяснено следующее - сегодня всем должно быть понятно, что with  в JavaScript совершенно бесполезная (местами вредная) конструкция. После этого Брендану был задан вопрос:
 -  Почему в 1995 году поддержка with в LiveScript казалась хорошей идеей?
На этот вопрос Брендан ответил так (правда с оговоркой на то, что если ему не изменяет память, то...):
 - ... это было не более, чем (желание услышать возгласы типа) "О-о-о, у вас есть поддержка оператора with - это круто!".