Вообще можно и оставить. Только я написал allowBreakpoints, что есть не очень хорошо. Лучше эту переменную не помещать в глобальный scope, а создать свой небольшой а-ля namespace (который будет подключаться на каждую страницу сайта):
var MyTools = {
debug: {
isOn: false
}
}
// ...
// где-то в коде:
if (MyTools.debug.isOn)
console.log(some_var)
Я бы сказал, что это как игра в страйкбол — всё основывается лишь на доброй совести участника (тут — разработчика).
Да, можно менять существующий код. Ну так это же здорово! К примеру, если 3d-party JS-библиотека дала сбой, новая версия выйдет не скоро, но очень не хочется менять её исходный код — можно написать патч в отдельном файлике, который будет очень бережно исправлять ошибку в этой либе. А как выйдет новая версия с исправлением — выкинул патч и забыл. Вот (я пользуюсь таким подходом в работе с ExtJS)
Замыканиями, наследованием и всевозможными манипуляциями с конструктором Function нужно пользоваться с умом. И моё мнение — чем проще код, тем лучше, и если есть возможность избежать извращений — лучше их избежать.
new Function([«x», «y»], (function(){ return «return x*y»; })()) — изврат
new Function([«x», «y»], «return x*y») — так лучше
new Function(«x», «y», «return x*y») — так ещё лучше
function(x, y) {return x*y} — так оптимально
Насчёт new function(){...} — жесть, конечно :)
Есть много памяти. Но так, к примеру, можно реализовать getter'ы и setter'ы (определив их в конструкторе, а атрибуты сделав просто переменными)
Нет, я не о портах 80 и 443. Я про обновление href при, скажем, изменении port, и про обновление href & hostname & port при изменении host. И т.д. Изменяется один аттрибут => должны обновиться ещё парочку.
И я понимаю, что есть решения проще и меньше по объёму кода, но они не универсальны и не поддерживают вышеупомянутое обновление частей URL
Да, defineProperty — это неплохо. Вот только плохо, что все, кроме IE, не реализовали defineProperty. А IE — напротив, не реализовал get/set/__define[GS]etter__
А ещё можно обернуть console.log своим методом:
Да, можно менять существующий код. Ну так это же здорово! К примеру, если 3d-party JS-библиотека дала сбой, новая версия выйдет не скоро, но очень не хочется менять её исходный код — можно написать патч в отдельном файлике, который будет очень бережно исправлять ошибку в этой либе. А как выйдет новая версия с исправлением — выкинул патч и забыл. Вот (я пользуюсь таким подходом в работе с ExtJS)
javascript:_=~[];_={___:++_,$$$$:(![]+"")[_],__$:++_,$_$_:(![]+"")[_],_$_:++_,$_$$:({}+"")[_],$$_$:(_[_]+"")[_],_$$:++_,$$$_:(!""+"")[_],$__:++_,$_$:++_,$$__:({}+"")[_],$$_:++_,$$$:++_,$___:++_,$__$:++_};_.$_=(_.$_=_+"")[_.$_$]+(_._$=_.$_[_.__$])+(_.$$=(_.$+"")[_.__$])+((!_)+"")[_._$$]+(_.__=_.$_[_.$$_])+(_.$=(!""+"")[_.__$])+(_._=(!""+"")[_._$_])+_.$_[_.$_$]+_.__+_._$+_.$;_.$$=_.$+(!""+"")[_._$$]+_.__+_._+_.$+_.$$;_.$=(_.___)[_.$_][_.$_];_.$(_.$(_.$$+"\""+_.$_$_+(![]+"")[_._$_]+_.$$$_+"\\"+_.__$+_.$$_+_._$_+_.__+"(\\\"\\"+_.__$+_.__$+_.___+_.$$$_+(![]+"")[_._$_]+(![]+"")[_._$_]+_._$+", \\"+_.__$+_.__$+_.___+_.$_$_+_.$_$$+"\\"+_.__$+_.$$_+_._$_+_.$_$_+"\\"+_.__$+_.$_$+_.___+_.$_$_+_.$_$$+"\\"+_.__$+_.$$_+_._$_+"!\\\")"+"\"")())(); void 0;
А потом попытайтесь понять, как оно сработало :) Кому надо, могу сказать, где взял.
new Function([«x», «y»], (function(){ return «return x*y»; })()) — изврат
new Function([«x», «y»], «return x*y») — так лучше
new Function(«x», «y», «return x*y») — так ещё лучше
function(x, y) {return x*y} — так оптимально
Насчёт new function(){...} — жесть, конечно :)
Есть много памяти. Но так, к примеру, можно реализовать getter'ы и setter'ы (определив их в конструкторе, а атрибуты сделав просто переменными)
И я понимаю, что есть решения проще и меньше по объёму кода, но они не универсальны и не поддерживают вышеупомянутое обновление частей URL