Цитата(Sardar @ 25.9.2006, 01:11  ) | | Zeroglif, parseFloat в любом случае вызываеться самим транслятором |
Так, да не так, parseFloat лексически является идентификатором, согласно ES 10.1.4 мы ищем идентификатор среди свойств объектов, входящих в Scope Chain, пока по идее не найдём его в поле объекта Global (window в браузерах). Плюс к этому, в рамках самого алгоритма функции parseFloat, который предполагает, что мы можем подсунуть ему всякую пакость (объект, например), аргумент насильно приводится к строке (toString у объектов). Значит, и тут мы снова должны совершить небольшую прогулку, но уже по полям самого объекта (его прототипа и т.д.), если аргументом объект. Да к тому же некоторые из нас имеют стойкую привычку нативные свойства переопределять, parseFloat конечно вряд ли тронут, а вот toString запросто. Добавим сюда до кучи более сложный алгоритм самой функции, чем алгоритм конвертации через унарный плюс или через Number().
Ниже пример, где видно, сколько объектов Scope Chain нужно пройти, и как переопределение toString влияет на parseFloat. А если раскомментировать параметр в функции A, то мы переопределим ("забъём") уже и parseFloat, и само собой получим ошибку.
| Код |
String.prototype.toString = function(){return 666};
var x = new String('10');
(function A(/*parseFloat*/) {
return function AA() {
return function AAA() {
return function AAAA() {
return parseFloat(x);
}();
}();
}();
})();
|
Я это всё не к тому, что дескать нехорошо переопределять свойства или совать в аргумент объект (всего этого скорее всего не будет!), а к тому, что короткий путь к результату правильнее длинного туда же..., а читабельность конечно же по вкусу  |
