Вероятнее всего — это баг. Потому как наблюдаю ПОЛНУЮ магию, например вот такое в 3.5 иногда работает (в зависимости от того, что будет выполняться):

thread.onreadystatechange = function () {

    /*thread.onreadystatechange = function () { };*/

    process.call(context);

    /* Magick! */

};

Наличие /* Magick! */ — обязательное условие!
В 3.6 не работает вообще.

странно.. фокс же вырезает комменты при парсинге..

Я понимаю, что бред, но почему то именно если коммента в конце нет — не работает.
Костыль с rethrow работает только в FF до 3.6, в 3.6 же ошибки даже в нём съедаются!

Вырубил Firebug и Console² — rethrow работает.

Проблема была в Console²

postMessage пробовали? (там, где он есть, разумеется)

З.Ы. Хотя не, он же асинхронный будет.

забавная зависимость о_0"

Зависимость между чем?

а, я тупой.. не обращайте внимание ^^'

Ну если вдруг нужны будут асинхронные "потоки", то postMessage быстрее setTimeout(0).

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

Да вроде нет, сначала рендерим, потом засекаем второй раз.

var endTime = Date.now();
printOutput("100 iterations of setZeroTimeout took " + (endTime - startTime) + " milliseconds.");
i = 0;
startTime = Date.now();
setTimeout(test2, 0);

Там где есть postMessage (а это, я так понимаю, FF, Chrome, Safari) можно сделать ещё проще — навесить на window свой кастомный эвент и будет работать как надо

рендеринг происходит после выхода из одного потока и до входа в следующий

Объясните мне тупому, почему все же отказались от решения с dispatchEvent ?

У меня следующий код вроде везде работает (кроме IE конечно):

var elem = document.createElement('div');
elem.onclick = function(e) {
	alert('Ok!');
};
var e = document.createEvent('HTMLEvents');
e.initEvent('click', false/* bubbles */, false/* cancelable */);
elem.dispatchEvent(e);

потому что не работает в ие

для IE у меня еще такой вариант получился:

var xmlDoc = new ActiveXObject('Microsoft.XMLDOM'), done = false;
xmlDoc.onreadystatechange = function() {
    if (!done) {
        done = true;
        alert('Ok!');
    }
};
xmlDoc.loadXML('');

но он медленный гад :( . done нужен потому-что событие срабатывает много раз и всякие this.onreadystatechange = null и xmlDoc.abort() его не отменяют.

tenshi, а зачем нужна фабрика, не проще сразу вызывать переданную функцию? Можно даже в Function.prototype добавить метод.

:nono:

Подойдет?!

var fragment = document.createDocumentFragment();
var node = document.createElement('div');
node.attachEvent('onpropertychange', function(){
	alert('Property change');
});
fragment.appendChild(node);
node.fireEvent('onpropertychange', document.createEventObject());

а что так?


Супер! Тоже что-то с DocumentFragment пробовал, но у меня почему-то не заработало :( .

UPD: афигеть, даже без attachEvent можно:

var elem = $d.createElement('div');
$d.createDocumentFragment().appendChild(elem);
elem.onclick = handler;
elem.fireEvent('onclick', $d.createEventObject());

моя счастлив :) .

Великое зло :)
Даже не пытайтесь переубедить.

Интересно, что этот код работает только в ИЕ8:

var fragment = document.createDocumentFragment();
var node = document.createElement('div');
node.attachEvent('onpropertychange', function(){
	alert('Property change');
});
fragment.appendChild(node);
node.innerHTML = '';

А вот если поместить его в документ, то всё ок.

Осталось только слить 2 скрипта вместе и готово.

не хочешь рассказывать почему, злодей! :)


ага, вот именно так я и пробовал, но тестил в IE6.

Да а что тут рассказывать, ты и сам всё понимаешь ведь :)
for..in...
Так то никто никому не запрещает, только советовать не надо.

А причем тут прототип Function?:)

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

Не понял, к чему это?
Просто for..in - это не агрумент против расширения прототипов стандартных объектов. По-моему, истинное зло - это использование for..in без hasOwnProperty ( я лично предпочитаю Object.keys( object ).forEach - мне так кайфовее:) ).

Вот и я не понял твоего вопроса.

Истинное зло - использование hasOwnProperty везде, во всех циклах. Далеко не всегда он нужен. Например:

function Conctructor(options){
  // Инициализация
}

Категорически запрещается использовать hasOwnProperty при проверки значений, т.к. объект options может наследовать от других объектов.
Не кроссбраузерно.

Просто речь зашла про расширение прототипа Function, а ты из аргументов, почему это плохо, привел только for..in. Вот я и спросил, причем тут прототип Function?Вот ни разу не однозначный пример. С одной стороны в прототипе могут быть дефолные значения, а с другой - лично я бы учитывал только свойства options, а дефолты должны быть в самом конструкторе.У меня - кроссбраузерно:p

ну вот, напугал только зазря, я уж подумал там какая-то супер-теория из потокового программирования.

Ага, я потом буду юзать твое API и в опции спецально передавать экземпляры, которые наследуют от других объектов. Ты этим поломаешь мне всё наследование. Хочешь узнать, какими словами я буду тебя вспоминать?!
Значит так надо!!!

Проверять надо тип значения, если чо. Это вообще отдельная тема.

UPD:
Дефолтные значения должны лежать рядом с конструктором.

B~Vladi, В твоих сообщениях ко мне (в этой теме) как-то дофига негатива (может мне кажется?), и мне это совершенно непонятно...

UPD: И вообще, твой пример никак не связан с циклом for..in!

function Conctructor(options){
  for(var prop in options) switch(prop){
    case 'some': ...
  }
  ...

Сомневаюсь, что так кто-нибудь (адекватный) будет делать.

B~Vladi,
тебя спрашивают, почему плохо расширять Function.prototype, а ты объясняешь, почему плохо расширять Object.prototype. Так в Object.prototype никто и не лезет.

Sweet, прости, я норм к тебе отношусь.
Ок, вот другой пример, когда есть дефолтные значения:

var defaultOptions = {};
function Constructor(options){
  for(var property in defaultOptions){
    if(defaultOptions.hasOwnProperty(property)){ // Проверяем только нужные свойства. Вот здесь hasOwnProperty обязательно.
      // Делаем нужные действия
    }
  }
}

Когда нет дефолтных значений, проверять нужно так:

function Constructor(options){
  // Допустим, нам нужно проверить конкретное свойство
  // Если тип не важен:
  if('prop' in options){}
  // Если важен:
  if('prop' in options && (/* тут проверка типа */)){} // prop in obj - тоже обязательно
}

Но никак не hasOwnProperty! Его нужно использовать только для "своих" объектов и то, если они не имеют кастомных прототипов.
Из этого видно, что значением может оказаться ваше кастомное свойство из прототипа.

Откуда ты можешь знать, из какого прототипа берутся значения? Если объект приходит извне и тебе нужны только значения свойств, нельзя смотреть на тип объекта. В примерах выше я могу в options передать и функцию, если мне будет так удобно.

Что я этим хотел сказать:
Если везде применять hasOwnProperty и проверять тип объекта - создаются ограничения, в частности, нельзя уже использовать наследование. Если расширять прототипы нативных конструкторов - они начинают везде обрабатываться, что может привести назад к использованию hasOwnProperty или даже к багу. Замкнутый круг. В каком месте его разрывать - каждый решает сам для себя, о чем я писал выше. Все полюсы и минусы я показал.

Насколько я понял, это выглядет примерно так:

function SomeConstructor( object ){
  this.property1 = object.property1 || 'default';
  this.property2 = object.property2 || 'default';
};

var func = function(){};
func.property1 = 'value';

Function.prototype.property2 = 'zapadlo';

new SomeConstructor( func ); // Тысяча чертей, почему property2 не 'default'???

Но для себя я решил, что имею полное право дополнять нативные конструкторы там, где считаю нужным. Что плохого в том, что я, например, добавляю в Array.prototype методы forEach, filter и пр.? Я, конечно, понимаю про for..in, но мы же знаем, как зовут тех, кто так переберает массивы?:)

Расширение Array.prototype, Function.prototype и т.д. менее опасно только из-за того, что их экземпляры используются в основном по назначению, а не для хранения/передачи свойств. forEach и filter это, конечно же, хорошо, но только потому что они есть в спецификации и в реализациях, поэтому безопасно.

Вот как-то так получилось:

Function.prototype.callAsync = function() {
	var self = this, args = $A(arguments), thisObj = args.shift(), elem = document.createElement('div'), done = false;
	elem.onclick = function() {
		if (!done) {
			done = true;
			self.apply(thisObj, args);
		}
	};
	if (document.createEvent) {
		var e = document.createEvent('HTMLEvents');
		e.initEvent('click', false, false);
		elem.dispatchEvent(e);
	} else document.createDocumentFragment().appendChild(elem).fireEvent('onclick', document.createEventObject());
	if (!done) setTimeout(elem.onclick, 15);
};

var $A = function(iterable) {
	if (iterable) {
		var result = [], i = iterable.length;
		while (i) result[--i] = iterable[i];
		return result;
	}
	return [];
};

var testFunc = function() {
	alert('testFunc');
	throw new Error('testFunc');
};

testFunc.method();
alert('global');
testFunc.method();
alert('global');

Почему безопасно? Они же тоже будут попадать в for-in.

Ну да, не совсем уж так и безопасно.

Но при этом мы знаем, что не надо перебирать массивы с помощью for-in, поэтому не боимся дописывать forEach/map/filter/... .

B~Vladi, ты прав, если неадекватные пользователи входят в целевую аудиторию решения (jquery way?), но все может быть проще :)

ссылка по смежной теме: What’s wrong with extending the DOM

https://github.com/sstephenson/proto...object.js#L112
+
https://developer.mozilla.org/en/JSON#section_12
=
epic fail

намекаешь на дефолтную реализацию исполнения ф-й в отдельных потоках?