Показать сообщение отдельно
  #59 (permalink)  
Старый 09.04.2009, 13:23
Аватар для Riim
Рассеянный профессор
Отправить личное сообщение для Riim Посмотреть профиль Найти все сообщения от Riim
 
Регистрация: 06.04.2009
Сообщений: 2,379

Сообщение от x-yuri
Riim, речь шла о сравнении innerHTML с nodeValue
Я уже давно понял и написал исправленный вариант. Посты № 47 и 51.

Сообщение от Zeroglif
У вас есть признак ноды, которая нужна (некий текст), проверяйте наличие этого текста и меняйте при наличии.
Я так и думал, что вы про это. Если проверять БЕЗ regexp-а, то почему бы и нет.

Сообщение от x-yuri
А стоит так мучиться для одноразового кода. Разве, что ради идеи
так ты определись, что мы обсуждаем. А то сначала ты говоришь про экономию операторов, а потом, что это одно разовый код
Экономил операторы я в TextNode.each, а это уже НЕ одноразовый код.
Я давно определился и уже объяснял как именно.
Я говорю про:
1) производительность
2) объем кода
3) логичность кода
4) читабельность
Приоритеты меняются в зависимости от кода.
В TextNode.each на первом месте производительность (универсальный код).
В window.onload объем кода (одноразовый код).
Читабельность всегда на последнем.

Почему именно такой порядок, я уже объяснял (с примерами) выше. Например, объяснял, как из-за не оптимизированного универсального кода появляются проблемы с производительностью, т. к. рано или поздно, он все равно становится узким местом в приложении.

Оптимизация одного часто делается в ущерб остальному. Вопрос в том, насколько эффективна эта оптимизация, и каков ущерб.
Дмитрий предложил вариант оптимизации производительности в ущерб объему кода. Ущерб слишком большой, а выигрыш в скорости мизерный (теоретически, не тестировал). Вариант предложенный Zeroglif (с проверкой до regexp-а), даст заметно большее увеличение производительности и меньший ущерб. Вполне приемлемый вариант.

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

Сообщение от Zeroglif
много варов внутри 'for' - необычно, глаз не радует, строку удлиняет, обычно задают не больше двух. Объявление переменной внутри цикла - бессмысленная вешь, провоцирующая ньюбов на лишние вопросы. Условный оператор обязан быть читабелен среди профи (в меру простой, конечно), ничего не имею против, но чаще всего не читабелен для других. Кроме того, с ним не очень приятно дорабатывать код, расширяя список выражений. С логическими операторами картина та же, в отсутствии присваивания они теряют в читабельности, к тому же есть пуристы, которые используют их только в логическом контексте
Я не хочу (без обид) вообще ни чего слышать про читабельность (в универсальном коде) в ущерб даже плюс одному байту кода после компрессора или плюс одному лишнему действию интерпретатора. Мой стиль не формируется, он уже сформирован, и до javascript2.0 я менять себя не собираюсь.


Сообщение от Zeroglif
Конструкция 'do-while' в примере может и была бы правильным выбором, если бы так нужно было проверять 'div.firstChild', а это не нужно
Как не нужно? Как же цикл тогда остановится?
Ответить с цитированием