Разве нельзя сделать тоже в случае, если используется setInterval? Т.е., если исчерпан лимит времени, то вызвать clearInterval?
Если у Вас имеется, к примеру, всего одна секунда, то в случае, если сначала будет выполняться что-нибудь этакое:
var start = new Date;
while ((new Date) - start < 1000);
то и setInterval, и setTimeout окажутся в равном положении. Разве не так?
Писать, что фича, объявленная еще в ECMAScript первой версии (1997 г.), не работает в современном браузере, претендующим на звание одного из лучших - это нечно, вроде провокации. ;)
Странноватый источник, кстати...
К тому, что написано "дядей" Джоном, бесполезно что-либо добавлять. Надо переделывать, причем с нуля. Проверьте свою "добавленную" функцию (а также оригинал) на такой строке параметров, выполнив скрипт в Firefox: 'watch=1&watch=2'
>несмотря на то, что написан он более 5 лет назад, зачастую нахожу в нем всю нужную информацию.
Все правильно, ведь справочник - это, так сказать, "азы", и они преподнесены, на мой взгляд, весьма толково и грамотно (а это большая редкость). Поэтому, что 5 лет, что 15 - неважно, материал будет востребован.
>если у кого будет желание, предложить нашему преподавателю продолжить работу над ним с нашей помощью.
Именно Вам посчастливилось иметь такого преподавателя, поэтому кому, как ни Вам следует брать инициативу в свои руки. Поднимайте упавшее знамя! ;)
key = key == 83;
То же самое и для "более элегантного решения", т.к. булева значения, которое возвращает оператор сравнения, вполне достаточно, чтобы не "городить огород".
Используйте в следующий раз какой-нибудь текстовый редактор с проверкой орфографии (статья ведь, как-никак). Просто подобная форма, не имеющая эстетической ценности, может запросто "зарубить на корню" весь интерес с содержанию.
>в каком-то месте работает оптимизация lookup-ов или где-то что-то кешируется (допустим, последнее значение)
Понаблюдал еще немножко, и вот что заметил. При сохранении значения ссылки на функцию в локальной переменной не видно различий в длине цепи property accessors (т.е. f = a.b.c и f = a.b.c.d.e.f.g.h – к счастью как-будто одинаково, как и должно быть). А вот вызов метода будет занимать разное время, которое варьируется от кол-ва "точек". В IE на "точки" уходит больше времени, чем в FF – в результате "точек" пять-шесть (к примеру) уравняют время исполнения (f() и a.b.c.d.e()). В FF "точки" "быстры" – чтобы время выполнения было одинаковым, нужно для пути к методу использовать весь алфавит. Вот тут и задумаешься – есть ли оптимизация lookup-ов? Вообще, если по уму, то быть обязана, но, как мне показалось (или может так оно и есть), больше "точек" – больше времени, и это сбивает с толку (т.е. где она, оптимизация?)...
Все же для того, чтобы сделать выводы нужно еще какие-нибудь тесты придумать. Пока в голове пусто...
Я обратился в другую группу - comp.lang.javascript. В ней, как-будто, активность больше, соответственно и шансов больше (если поймут мой "ломаный"). Правильно сделал? Или в netscape.public.mozilla тоже написать?
Я решил, что суть в следующем. Когда функция в качестве this value получает в свое распоряжение null (это именно тот случай, когда функция вызывается, как e(), и base object => activation object), то появляются дополнительные расходы на подстановку global вместо этого null. Под "дополнительными расходами" я подразумеваю то, что у них (во всяких monkeys) неоптимизирован алгоритм именно получения значения global, т.е. используется какая-нибудь медленная функция, типа js_ComputeGlobalThis. И это настолько "медленно", что в результате "съедается" вся оптимизация (избавление от операторов точка).
Разве нельзя сделать тоже в случае, если используется setInterval? Т.е., если исчерпан лимит времени, то вызвать clearInterval?
Если у Вас имеется, к примеру, всего одна секунда, то в случае, если сначала будет выполняться что-нибудь этакое:
var start = new Date;
while ((new Date) - start < 1000);
то и setInterval, и setTimeout окажутся в равном положении. Разве не так?
Писать, что фича, объявленная еще в ECMAScript первой версии (1997 г.), не работает в современном браузере, претендующим на звание одного из лучших - это нечно, вроде провокации. ;)
Странноватый источник, кстати...
А метка-то здесь зачем?
>if(js == undefined) var js = {};
Странное условие...
> Первое что пришлось сделать, так это преобразовать вид старых функций... поскольку только так функции подгружались.
:)
К тому, что написано "дядей" Джоном, бесполезно что-либо добавлять. Надо переделывать, причем с нуля. Проверьте свою "добавленную" функцию (а также оригинал) на такой строке параметров, выполнив скрипт в Firefox:
'watch=1&watch=2'
Все правильно, ведь справочник - это, так сказать, "азы", и они преподнесены, на мой взгляд, весьма толково и грамотно (а это большая редкость). Поэтому, что 5 лет, что 15 - неважно, материал будет востребован.
>если у кого будет желание, предложить нашему преподавателю продолжить работу над ним с нашей помощью.
Именно Вам посчастливилось иметь такого преподавателя, поэтому кому, как ни Вам следует брать инициативу в свои руки. Поднимайте упавшее знамя! ;)
Нет никакого "объекта" null - есть примитивное значение. И это значение типа Null.
То же самое и для "более элегантного решения", т.к. булева значения, которое возвращает оператор сравнения, вполне достаточно, чтобы не "городить огород".
Я думал, что достаточно будет обратить внимание программиста на строку...
Что ж, еще раз (конкретнее): key == 83 ? 1 : 0
key = !isGecko ? (key == 83 ? 1 : 0) : (key == 115 ? 1 : 0);
???
Используйте в следующий раз какой-нибудь текстовый редактор с проверкой орфографии (статья ведь, как-никак). Просто подобная форма, не имеющая эстетической ценности, может запросто "зарубить на корню" весь интерес с содержанию.
Да тут вообще кошмар (при беглом просмотре):
Точно не будет?
Понаблюдал еще немножко, и вот что заметил. При сохранении значения ссылки на функцию в локальной переменной не видно различий в длине цепи property accessors (т.е. f = a.b.c и f = a.b.c.d.e.f.g.h – к счастью как-будто одинаково, как и должно быть). А вот вызов метода будет занимать разное время, которое варьируется от кол-ва "точек". В IE на "точки" уходит больше времени, чем в FF – в результате "точек" пять-шесть (к примеру) уравняют время исполнения (f() и a.b.c.d.e()). В FF "точки" "быстры" – чтобы время выполнения было одинаковым, нужно для пути к методу использовать весь алфавит. Вот тут и задумаешься – есть ли оптимизация lookup-ов? Вообще, если по уму, то быть обязана, но, как мне показалось (или может так оно и есть), больше "точек" – больше времени, и это сбивает с толку (т.е. где она, оптимизация?)...
Все же для того, чтобы сделать выводы нужно еще какие-нибудь тесты придумать. Пока в голове пусто...
Да-а-а. Что ж они там "натворили" в последних версиях (в старых-то быстрее в два раза x())?
Да не-е-е, не придирка вовсе! И не зряшная, как оказывается, т.к. Вы начинаете давать подсказки (это я о this). ;)