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

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