FTread, исполнение функций в отдельных потоках

[B~Vladi]

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

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

[Sweet]

for..in...

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

[B~Vladi]

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

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

[Sweet]

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

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

[B~Vladi]

Не понял, к чему это?

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

По-моему, истинное зло - это использование for..in без hasOwnProperty

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

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

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

Object.keys( object ).forEach

Не кроссбраузерно.

[Sweet]

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

Просто речь зашла про расширение прототипа Function, а ты из аргументов, почему это плохо, привел только for..in. Вот я и спросил, причем тут прототип Function?

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

Вот ни разу не однозначный пример. С одной стороны в прототипе могут быть дефолные значения, а с другой - лично я бы учитывал только свойства options, а дефолты должны быть в самом конструкторе.

Не кроссбраузерно.

У меня - кроссбраузерно

[Riim]

for..in...

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

[B~Vladi]

лично я бы учитывал только свойства options

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

С одной стороны в прототипе могут быть дефолные значения

Значит так надо!!!

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

UPD:

дефолты должны быть в самом конструкторе

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

[Sweet]

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

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

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

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

[Kolyaj]

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