Как вы считаете правильнее?
 

function lb_confirm(options) {
options = (typeof(options)==='object' ? options:{});
}

или

function lb_confirm(options) {
options = options || {};
}

Я лично за вариант 2, так как считаю №1 лишней смысловой нагрузкой
Те, кто будет использовать данную ф-ю в дальнейшем, должны знать, что они передают в нее.

function multiply(a, b = 1) {}
нативный js так не умеет

Да, а если бы это было нужно, было бы совсем хорошо.

Кстати, этот подход, насколько я понимаю, значительно урезает гибкость

Object.prototype.optional=100
f=function(optional){with(this) return optional||"fuck"}

console.log(f())

delete Object.prototype.optional

console.log(f())

console.log(f(200))


//>>>> 100
//>>>> fuck
//>>>> 200

fuckJS,
Каким образом?

Так я же пример привел, из него разве не видно? Выражение function(opt=1){...} всегда будет перекрывать. То есть, при отсутствии аргумента у тебя будет всегда дефолтный, независимо от того, какому объекту ты отсылаешь сообщение, и есть ли у него это свойство. Насколько я понял из описания, может ошибаюсь.

optional=100
f=function(optional){with(this) return optional||"fuck"}
console.log(f())

так по проще. тут ты делаешь глобальную область видимости приоритетнее локальной, в которой переменная option хранит undefined
на мой взгляд это извращение и так делать не стоит

глобальная область тут вообще не при чем. Там свойство объекта приоритетней, любого объекта, не обязательно верхнего.

в данном случае this это объект window. Да, это понятно. Спасибо, что поправил.

используй транслятор

Просто ты сидишь с хромоподобного браузера, который этого ещё не поддерживает. Открой консоль FF и запусти там свой код - всё будет работать. Если хочешь поддержку во всех браузерах, то используй Babel.js.

fuckJS, забудь про with, ибо в стрикте он всё равно не работает.

typeof null === typeof {} === 'object' - в этом случае ты рискуешь впоследствии обратиться к null, как к объекту и при этом получить ошибку
С другой стороны
options = 1 , options ? options : {} тоже может дать неожиданный результат, если требуется объект с ограниченным набором возможных полей... обычно так бывает в универсальных методах, где объекты, например, копируются в цикле, а не по полям. Ну и остается риск перетереть поведение всего типа, если обращаешься где-нибудь к прототипу этого объекта. Я подобную ошибку случайно нашел в весьма крупном проекте, причем эта ошибка проявлялась только в IE и потому была трудно уловима. А ведь из-за нее мог грохнуться пользовательский интерфейс...

Я всегда делаю комплексную проверку typeof options === typeof {} && options ? options : {} - в этом случае всегда получишь объект.

Это и есть нативный JS. Новая версия просто.

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

ты имеешь ввиду перезапишется по ссылке? давай по подробнее) интересно, что за баг был

Трансляторы для лохов?

alert(typeof null == "object");

тссс... не шумите. Не упрощайте людям жизнь :D

Erolast,
Для отморозков слабых умом. Настоящие профи пишут на ES3. В одну строку.

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

до до до, айкидо :D

Именно в том и суть, чтобы привыкать. Когда придёт время ты уже будешь иметь приличный опыт и тебе не придётся мучительно переучиваться или писать по-старому бездарно растрачивая своё время.

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

nerv_, Aetae,
ребят, не тратьте время) Он либо тролль, либо просто не понимает о чём речь(даже после подробного описания).

сам ты троль)
иди в доту рубись

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

Я тебя понимаю, но я с детства привык изучать все по мере надобности, из-за этого сложно давалась учеба, но с этим подходом сейчас работаю в крупнейшей Российской компании web разработчиком и имею свои собственные проекты. В общем, когда это будет стандартом во всех браузерах, обязательно втянусь. А сейчас пока смысла не вижу. От себя еще хочу добавить: может 100% примут стандарт этот все браузеры, но еще когда, через год-два, больше?
Я еще стараюсь тянуть решения для своих разработок под ie 7, а сколько времени после, мне этот костыль потребуется в свои разработки вставлять? В общем, это только мое мнение, я никому его не навязываю, и уважаю чужое мнение.

Был в моей практике случай, когда один фреймворк каким-то веселым чудом поменял поведение массивов... всех массивов вообще. Я толком не разбирался, как именно это вышло, лишь знаю в тысячах строк фреймворка идет работа с Array.prototype. Суть в следующем. Массив можно перебирать, как и объект, через for (var key in array) - это даже в документации написано (я специально на всяких w3...- сайтах искал). И на самом деле все браузеры так и делали. При этом для массива перебираются только его индексы. Однако после применения того фреймворка в IE у меня стали в качестве ключей вылезать length и еще какие-то ключи. Что-то там было через прототипы изменено. Очень повезло, что ошибка быстро обнаружилась и не пришлось делать глобальных переделок.

И кстати, не просто typeof null == 'object', а typeof null === 'object'. Просто лично я не использую сравнение со строкой из-за паранойи... а вдруг в каком-нибудь тупом браузере будет не 'object', а 'Object' или 'OBJECT'... Тогда и проверка без учета типа провалится... Но это скорее всего именно паранойя... дождемся Спартанца из десятки))))

у меня тоже пару месяцев назад такое было)) length влезал в массив, пару дней отлавливал. Какой-то девелоп поставил на ту страницу сайта библиотеку, со странным перебором for по массиву, тоже долго ругался)
я так тоже не использую, просто меня один коллега отчитал, что не использую полную проверку(использую №2) я вот и решил конкурс запилить, сам уже ответил, как аргументирую свою позицию:да и его вариант оказался недостаточно правильным, так как не обрабатывает null, я чет сразу не втыкнул в это, тут ребята показали)

Тогда уж просто options = options || {} (оператор || возвращает не булево, а первый операнд, приводимый к true).

Просто такая запись for (var key in array) короче и приятнее, при этом не теряет читаемости.

Век живи, век учись. Кто-то в интерфейсах редактирования при создании некоего нового объекта предпочитает создавать сразу пустую структуру со всеми необходимыми полями и т.д. и ему никогда и нигде нет надобности проверять на null, а другой наоборот не заморачивается с созданием объекта, с поддержанием соответствия кода архитектуре БД, но испытывает необходимость на полную проверку. У каждого свой стиль и свои потребности))

Да, спасибо, в моем первом сообщении именно так)
только это считаю не совсем правельным(по идее при результате должен быть boolean), так php тоже считает.

у меня через for по массиву работала библиотека raphael.js, т.е. ее переписывать было нежелательно. Выпилили то поведение, которое было у for и переписали куски кода, предназначенного для этого поведения