имелось ввиду, что собственно new, занимается созданием нового объекта, прописывает ему корректный prototype, а функция-конструктор только инициализирует этот объект согласно коду в теле функции.
Если под '«инстарцируя» объект' подразумевается создание объекта — но это не верно для call/apply: call/apply не «инстанциируют» объект. Они просто выполняют функцию в контексте указанного объекта. Т.е.
(function (x) { this.x = x; }).call({}, 5);
не является эквивалентом:
var o = new function (x) { this.x = x; }(5);
потому что new делает еще кое-что за нас:
var New = function (f) {
var o = {};
return function () { return (f.apply(o, arguments), o); };
}
> У вас там во-первых два лишних return: «return Private(this, new Foo(x))»
Так-то оно так, да не совсем ;-) Тынц: var bar = Foo.call(new Bar(«some-value»), 333);
> вместо дублирования самих методов в объектах имеем кучу оберток в этих же самых объектах… плюс к тому дополнительный оверхед при дальнейшем вызове методов.
Это вопрос эффективности реализации JS, имхо, а не языка как такового. Кстати, JIT вполне может помочь в этом вопросе.
> можем иметь в таком «как бы объекте» (который состоит из двух других) два свойства priv_x
Можем, конечно! «даже с помощью первоклассных инструментов можно делать г*веные вещи». ;-)
Я просто показал концепт, который позволяет не заморачиваться на локальные переменные, не плодить кучу локальных замыканий в явном виде, а писать «по-старинке» через prototype, ничего кардинально не меняя в коде, но получая при этом требуемый эффект приватных мемберов «класса».
> Невозможно получить доступ к свойству объекта с помощью строкового литерала, например вот так this[(a > 2? 'max': 'min')]
> Казалось бы мелочь, но неприятно.
> Объекты с приватными свойствами сложнее в отладке.
> При эмулировании приватных свойств в JS, нам придется везде в коде добавлять или убирать this. перед обращением к свойству.
Я предпочитаю раскладывать объект на две составляющих — никаких проблем ни с отладкой, ни с переносом public/private свойств. Чего и Вам советую ;-)
Интересно было бы прикинуть бюджет на все перечисленные операции и сопоставить его с бюджетом на непосредственную реализацию фич. Склоняюсь к паритету :)
> Если не нравится долгая реакция официального Net Cata на информацию о баге — смените CMS, выберите другую, их ведь полно.
Если бы все рассуждали как Вы, мы бы до сих пор получали бажные процессора от Intel, сидели бы в дырявом-предырявом IE под Windows 2009, сделанной наспех на костях Windows 95 и сетовали бы мол «жизнь не удалась».
Buffer overflow — это несколько больше, нежели просто крешнуть браузер. Да и 9000 вирей ни к чему. Достаточно одного толкового трояна и +1 ресурс в ботнете. :P
Мозилла пожертвовала качеством в угоду популярности — вель могли же еще в бете месяц-другой повисеть, но нет. Нужно было поддержать окученную долю рынка.
Теперь 90% леммингов Интернета будут говорить примерно так: «поставить Firefox? это который Mozilla? Так он же глючный и вообще. Я точно знаю, мне Одмин рассказывал!». Такие дела…
Microsoft решила откусить кусочек Linux/BSD хостинга, переманив PHP-шнегов на свой заоблачный хостинг. Прокол в том, что под Windows PHP-приложения, вероятно, придется обрабатывать напильником, и, к тому же, оценка практического применения Zend Framework сильно завышена, имхо.
(function (x) { this.x = x; }).call({}, 5);
не является эквивалентом:
var o = new function (x) { this.x = x; }(5);
потому что new делает еще кое-что за нас:
var New = function (f) {
var o = {};
return function () { return (f.apply(o, arguments), o); };
}
var f = function (x) { this.x = x; };
alert(New(f)(5).x); // 5
var foo = function(){this.b = 5; return {a: 6};}
var o = new foo();
alert(o.b); // undefined
alert(o.a); // 6
Вывод: если конструктор объекта возвращает (любой) другой объект — то this-объект, созданный конструктором, теряется.
Так-то оно так, да не совсем ;-) Тынц: var bar = Foo.call(new Bar(«some-value»), 333);
> вместо дублирования самих методов в объектах имеем кучу оберток в этих же самых объектах… плюс к тому дополнительный оверхед при дальнейшем вызове методов.
Это вопрос эффективности реализации JS, имхо, а не языка как такового. Кстати, JIT вполне может помочь в этом вопросе.
> можем иметь в таком «как бы объекте» (который состоит из двух других) два свойства priv_x
Можем, конечно! «даже с помощью первоклассных инструментов можно делать г*веные вещи». ;-)
Я просто показал концепт, который позволяет не заморачиваться на локальные переменные, не плодить кучу локальных замыканий в явном виде, а писать «по-старинке» через prototype, ничего кардинально не меняя в коде, но получая при этом требуемый эффект приватных мемберов «класса».
загляните в любой хаброJSник — код написан именно «кое-как», особенно там не не скопитырен, а написан самостоятельно.
> Казалось бы мелочь, но неприятно.
> Объекты с приватными свойствами сложнее в отладке.
> При эмулировании приватных свойств в JS, нам придется везде в коде добавлять или убирать this. перед обращением к свойству.
Я предпочитаю раскладывать объект на две составляющих — никаких проблем ни с отладкой, ни с переносом public/private свойств. Чего и Вам советую ;-)
Концепция подхода описана тут: code.google.com/p/nulljs/wiki/HowtoPrivateMethods
Если бы все рассуждали как Вы, мы бы до сих пор получали бажные процессора от Intel, сидели бы в дырявом-предырявом IE под Windows 2009, сделанной наспех на костях Windows 95 и сетовали бы мол «жизнь не удалась».
Мозилла пожертвовала качеством в угоду популярности — вель могли же еще в бете месяц-другой повисеть, но нет. Нужно было поддержать окученную долю рынка.
Теперь 90% леммингов Интернета будут говорить примерно так: «поставить Firefox? это который Mozilla? Так он же глючный и вообще. Я точно знаю, мне Одмин рассказывал!». Такие дела…
Вот что бывает, когда маркетологи бегут впереди основного состава.
>… или удалить с помощью оператора delete ( delete someVar; )
Развод и профанация. НЕЛЬЗЯ удалить переменную с помощью delete. Автор, учи матчасть!
а как же BSD games? :)
Моск подвис на этой фразе…
Слишишь? Ти умный такой, да?
mov ax,
and ax, 1
jz l_odd_value
~penis-comparator mode off~
ЗЫ. А вообще, тут какбэ топик про нейронки :-P
Спасибо, поржал.