Zeroglif

Все вместе правы одновременно. С одной стороны, если нужно показать схему решения, то нам не нужна ни "одноразовая" переменная, ни лишняя функция. Отсекать лишнее - правильно. С другой стороны, если вопрос исходит от ньюба, то он может начать копипастить в лоб - не будет кешировать ноду, не разберётся с объединением действий в одной функции и т.д. Чтобы "лишнее" не резало глаз можно было бы просто написать комментарии о возможных дополнительных обращениях и проч. И фффсё...

Как же сделать чтобы разбивка произошла по первому делителю?

У строк есть свои достаточно гибкие методы, подойдёт для такого случая, к примеру:

var s = 'man+woman=sex=children=problem', i = s.indexOf('=');
alert( s.slice(0,i) );
alert( s.slice(i+1) );

Даже если туда передаётся строчка.

Эт вряд ли, по ES строка от рега отделена в алгоритме (функция SplitMatch). Это теория. Практику можно проверять, подозреваю, большинство движков будут возиться с регом существенно дольше.

Двукратное превосходство строкового разделителя есть только в том же Сафари.

В IE разница не более 10%.

В FF2 - около 25%.

Оперу не тестировал

От теста зависит, у меня FF3 медленнее в 2 раза, Опера9.63 в 5-6!!! раз, IE6 чуток, Хром почти одинаково...

2 Zeroglif, да точно. спасибо. заодно пересмотрел манулы. мой пример не в тему

Он может быть в тему, если с другой стороны взглянуть - с точки зрения внимательного отношения к вложенным функциям, пережившим контекст в котором они были созданы. Часто бывает, что во внешней функции куча локальных данных, но замыканию нужна только часть из них, остальное удерживается просто так, заодно, т.к. замыкание "помнит" не значения, не отдельные свойства, а Scope целиком. Трудно сказать, что движки делают с "как-бы-не-нужными" замыканию свойствами, оптимизируют или нет.

В JavaScript насколько я помню в 99% случаев параметр передается по ссылке, а не по значению.

Параметр передаётся по значению.

Но экземпляр сreateMyObject не может быть удален из памяти, потому что на него ссылается MyObject0, точнее на локальную переменную localVariable функции сreateMyObject с конкретным значением.

Функция 'createMyObject' живёт сама по себе, её уже держит несколько объектов - прототипы созданных объектов (через свойство 'constructor'), variable object того контекста, где этот конструктор создан (через window.createMyObject). Наличие переменных или параметров внутри внешней функции не влияет на то, как вложенная функция "запоминает" Scope, она это делает в любом случае, пусто там или не пусто.

Конструктор переходит в неактивное состояние. Память для хранения его переменных не требуется. Он отработал свое и лежит формально, пока не будет вызван.

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

Для пояснения приведу расширенный пример

function createMyObject (inp) {
	  var localVariable = {value: inp};
	  this.alert = function () {return localVariable.value}
}

MyObject0 = new createMyObject ('local1');
MyObject1 = new createMyObject ('local2');
alert([MyObject0.alert(), MyObject1.alert()]);

Теперь у нас в динамической памяти два экземпляра конструктора и по одному экземпляру объекта. Итого 4 объекта. каждому нужна память, для хранения своих свойств.

Экземпляры на то и экземпляры, чтобы быть единственными в своём роде. Конструктор (createMyObject) как был один, так и есть один, объект {value:inp}, как и метод alert создаются при каждом вызове конструктора.

Какой объект занимает память в первом случае и не занимает во втором?

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

то Вы считаете глупыми такие фирмы, как Google, w3c, DELL, Intel

Ага, считаем. В js-программировании.

Я вчера снова с комуняками сцепился.

Похоже, это B.Новодворская до форума добралась. При помощи книжки "JScript is the best JavaScript" 1997 года выпуска, Валерильнишна с трудом, но вс?-таки внедрилась в здешнюю профессиональную среду, затем мастерски расфокусировала наше внимание, выпустив потешные лучи ненависти в сторону Оперы-жоперы и, наконец, когда число просмотров топика приблизилось к тр?м тысячам, сбросила маску первобытного яваскриптера и приступила к выполнению своей основной задачи - "комуняки - зло, КГБ - зло, комуняки - зло, КГБ - зло...". :)

туча итераций в вашем dcss тормозит такую простую табличку, что просто ЖЕСТЬ!

Там нет так называемого dcss (IE behaviors), обычный скрипт, просто он так написан.

Дима, в ослике только и работает. Я не знаю как писать в Жопере. Она очень капризна, как компьютер совдеповского производства.

Вы судя по всему просто не знаете, как программировать на js кроссбраузерно. Скрипт на странице "про умножение" настолько прост по своему смыслу, что бедной Опере там даже не на чем капризничать. Выныривайте же, наконец, из девяностых годов и начинайте изучать кроссбраузерное программирование вместо того, чтобы терять время на смешные безаппеляционные выпады в адрес достойных браузеров. Когда научитесь - найд?те в сво?м скрипте 4-5 ошибок и упс... произойд?т чудо...

Мне жаль, что у IE нет конкурентов.

Лучше "IE рулит, остальные - сосут!", взялись провоцировать тут холивар - надо действовать ж?стче. :mad:

homm,

Дополню. Смешит целенаправленное прописывание в тексте литералов true и false, если учесть, что любое вернувшееся из функции значение при дальнейшей проверке, допустим, при проверке через if() в следующей функции будет снова конвертировано в значение типа Boolean и проверено. То есть вы легко можете выпустить из функции непосредственно req, будь в этой переменной null или object, не важно. Если же вы вс?-таки страшно захотели вернуть именно булев, то опять-таки конвертируйте req на месте (во флажковом стиле - !!req или более сложно, но нагляднее - Boolean(req)), а прописывать руками в такой операции тру и фалс - это как-будто на минуту забыть про конвертацию типов в javascript вообще. Масло масляное. И последнее - в вашей функции уже проверялось значение req, из этой ветки можно было и вернуть необходимое значение, не дублируя проверку...

Можешь прочитать коментарий в моем посте с XMLLoad.

У каждого браузера своя собственная реализация XMLHttpRequest (если она есть), она может быть почти какая угодно с точки зрения объектов в стандарте ECMA-262 или комформной/не комфорной с точки зрения документов W3C, но разная реализация никак не отвергает тот факт, что в IE7+ появился и может быть использован отдельный XMLHttpRequest Object заодно с единственно возможным ранее объектом ActiveX. Отсюда фраза: "XMLHttpRequest так до сих пор в ИЕ и нет, его эмулирует ActiveX" приблизительно такая же правильная и точная, как и фраза оппонента про то, что "XMLHttpRequest появился ещ? в IE4".

AKS, вы хотите местный холивар про "жоперу" и флейм про "шизофреников" возвести в степень? Только jQuery тут и не хватало. Если дело выгорит, то я уже точно не вытерплю и вступлю с темами "bmw vs. гнусный мерин" и "плазма pioneer vs. гов?нный панас"...

Алекс, homm,

как же вы весело спорите - один говорит, что XMLHttpRequest появился ещ? в IE4, другой говорит, что самого XMLHttpRequest так до сих пор в IE и нет. Молодцы.

в какую версию IE впендюрили XMLHTTP впервые?

в какую версию IE впендюрили XMLHTTP в виде нативного объекта XMLHttpRequest?

Модераторы ещ? живы или уже все вымерли от смеха? Перенесите же, наконец, эту ветку из javascript-a куда-нибудь на Луну...

Вам это ясно

Ну, я, например, не знаю ответ на вопрос "почему?". Почему изменилось поведение Оперы?

кто из них (IE/Opera8+/Opera<8) сделал все правильно?

Opera;)

Пользуюсь оперой несколько лет (но сейчас переш?л на фаерфокс) - ни разу не менял строку... Зачем???

Вы не меняли, за вас Опера меняла, не спросясь. Имеет полное право. А тому, который меняет, личный опыт того, который не меняет, поможет слабо.

Я на такие сайты просто забиваю - есть множество других, которые предложат то же самое, но в любом браузере.

Сомневаюсь, что забиваете. Вы по таким сайтам ходите каждый день.

На ориентировочный момент написания скрипта Опера по дефолту представлялась как "Netscape", заодно и "Microsoft Internet Explorer". Так что программист, названный тут имбецилом, вообще не отсекал Оперу, и скрипт прекрасно работал, как бы вы его тут не переводили на свой язык. Сегодня куча браузеров разрешает трогать свои "идентифицирующие" строки, другая куча народу этим пользуется, спуфят чего не попадя, а тем более достаточно продвинутые пользователи Оперы. Поэтому любой скрипт для незнакомой среды, базирующийся на строках агентов (UA), по сути может работать или не работать с любым браузером. Наличие строк однозначно говорит только о наличие строк и ни о ч?м больше.

Переводу на русский (для Zeroglif`а)

Гы. Подвигаю-ка я особо настойчивых в правильном направлении:

1) Является ли значение свойства 'appName' однозначным идентификатором конкретного браузера?

2) Каким было это значение у Оперы во времена, когда был написан этот скрипт (где-то 1999-2000гг.)?

3) Может ли пользователь современной Оперы самостоятельно менять значение 'appName' в настройках?

4) Могут ли пользователи других браузеров самостоятельно менять значение 'appName'?

Ответы на эти вопросы должны привести к правильному пониманию скрипта. Если понимание не прид?т, то прид?тся мне выкладывать алерты, свидетельствующие о том, что и современная Опера этот скрипт обработает, и тем более Опера врем?н написания скрипта, допустим, какая-нибудь 3.60...

AKS,

когда homm and zoNT настойчиво тут разъясняют "идиотам", что скрипт "написан так, чтобы он ничего не делал в Опере (и других браузерах, кроме ИЕ и мозиллы)" - это конечно же неправда, этот скрипт может работать или не работать в любом из браузеров. Почему он не работает у задавшего вопрос в Опере и чья тут вина решайте сами.

У Вас, на мой взгляд, такое же предвзятое отношение к Opera, как у других к IE.

В отношении javascript-a (если включить туда же BOM/DOM и т.п. и не считать последние пару лет) Опера всегда была самой непредсказуемой и фиче-неподдерживающей при самом быстром (за исключеним некоторых мест) движке. К тому же никак это не документировала, чем ещ? больше осложняла жизнь js-программисту. И в том, что у человека (про которого, кстати, тут все уже забыли) не заработал в Опере этот архаичный скрипт, виновата в какой-то степени и сама Опера...

Товаришь, вы идиот?

В этой ветке единственный разумный - Emm, в его скромном посте ключ ко всему.

В коде выше стоит прямая проверка на то является ли текущей брузером ие или мазиллой или нет

Другая там проверка. Потешная.

И это не проблема оперы

Это проблема Оперы в том числе.

это проблема того имбицила-программиста

Мало, кто пишет скрипты на 10 лет впер?д. Вы пишите?

/********************************************************
cssFloat --> код не для всех --> неправильно
styleFloat --> код не для всех --> неправильно
... --> код не для всех --> неправильно

cssFloat + styleFloat + ... --> кроссбраузерный код --> ???
*********************************************************/