Работа с объектами в JavaScript: теория и практика

Да не то чтобы часто, но на JavaScript не один же я пишу :) Кто его знает, что там у людей происходит в процессе разработки.

В общем да, пожалуй стоит об этом написать, как об одной из возможностей, но даже пока не знаю, стоит ли апдейтить данную статью или заводить новую.

Причем брат того, кто придумал Перл…

> о будущем вам думать некогда

Если б он заглянул в будущее Нетскейп Навигатора, то быстренько бы уволился, какой там язык… ;)

> Но числами индексировать хочется — так давайте их автоматом преобразовывать!

Массивов изначально не было, зато с каждым свойством объекта дополнительно корреспондировал индекс того же объекта.

подсыпь кармы — рассужу =)

А зачем нам «конструктор» и «сделай_на_основе_конструктора»?

А это уж у Covex'а нужно спросить. Если мы хотим по разному создавать объекты, являющиеся прототипами и не являющиеся таковыми — но нам нужны две разные функции. В большинстве случаев это действительно не нужно.

Ладно бы Вы штамповали каскадно объекты через фабрику, но это здесь — уже создана «порождающая сущность» (конструктор), но потом еще и «порождающая-порождающая сущность».

Эта так же раница, которая в C++ имеется между operator new класса и конструктором, а в Java — между конструктором и фабрикой. Порождать это дело руками или автоматом — дело вкуса.

> А смысл городить такие конструкции, если можно просто не делать в конструкторах ничего, кроме инициализации свойств дефолтными значениями?

Ну компромисс — есть компромисс. И подобных компромиссов «а смысл?» можно тогда в любом месте напихать (тогда вообще, смысл может отпасть и достаточно будет линейного (даже не процедурного)) программирования (безо всяких классов и прототипов).

К тому же, иногда, кто-то в конструкторе (или методе init (если еще и для конструктора будет враппер) — не важно) может выдать системное сообщение.

> Ведь если цель — сократить объем кода и избежать лишних сущностей, то метод с wrapper все равно не позволяет ее достигнуть.

Ну вот в эти моменты люди и начинают писать функции-обертки (и часто называют их «классами»), где эти манипуляции с __wrapper'ами скрыты, но обеспечивают наследование. Естественно, никто не заставляет каждый раз писать этот кусок кода — вынесете его в обертку и создавайте объекты через нее (это всего лишь улучшение code reuse).

не, ну можно, конечно, написать что-то вроде:

Animal= function(){
var func= function(){
// init
}
func.superconstructor= arguments.callee;
return func;
}()

Cat= Animal.superconstructor();

но это изврат ;-)

Как это никак нельзя клонировать функцию без eval?
А binding`и уже отменили?

function GBind(oContext, fFunctor) {
    return function () {
        return fFunctor.apply(oContext, arguments);
    }
}

или что-то другое имелось под клонированием?

Хм, может как-то так?
function class( methods ){
return function(){
if( ! this.constructor ) return null;
....
}
}
var animal = class({...})
var cat = new animal( args )


Имхо, на статью не тянет =( Кода гораздо больше, чем текста:

var a = function() { this.c = 0; }
a.prototype.set = function() { this.c++; }
var b = function() {
 this.c = 0;
 this.set = function() { this.c++; }
}
function T(T1) {
 var T2 = new Date().getTime();
 if (T1) alert(T2-T1);
 return T2;
}

var i, T1, cnt = 100000, obj;
/* Первый тест: много созданий объекта и вызовов функции */
T1 = T();
for (i=0; i<cnt; i++) {
 obj = new a();
 obj.set();
}
T1 = T(T1);
for (i=0; i<cnt; i++) {
 obj = new b();
 obj.set();
}
/* На первый тест тратится на много меньше времени, чем на второй т.к. в первом случае на создание нового объекта set не тратится время */

/* Второй тест: одно создание объекта и много вызовов функции */
T1 = T(T1);
obj = new a();
for (i=0; i<cnt; i++)
 obj.set();
T1 = T(T1);
obj = new b();
for (i=0; i<cnt; i++)
 obj.set();
T1 = T(T1);
/* На первый тест тратится немного больше времени т.к. во втором случае не нужно искать функцию в прототипе объекта */

* This source code was highlighted with Source Code Highlighter.

сабжевого

а, т.е. был один ==, который не учитывал типы? и 1 == '1' было false, да?

Наоброт 'popa' == 0 было true. NaN появился позже.

Что значит «нельзя было надежно сравнить»? А как в других («не дерьмовых») языка дело обстояло в то время?

Как и должно быть, собственно: если типы разные — то объекты разные, если справа и слева один объект — то они уж точно равны :-) Вот если типы одинаковые и объекты разные — можно двигаться дальше. Ту заплатку, которую в результате придумали сложно назвать вменяемой: в JavaScript a==a может быть false и даже a===a может быть false — что как бы несколько дико...function surprise() {
  test.arguments.i = 2;
}
function test() {
  var i=1;
  surprise();
  alert(i); // Ой какой surprise!
}
test();

Как и в любой разрботке, которая эволюционирует. А какие Вы видели «недерьмовые» эталонные разработки?

Pascal, Java, даже где-то C или Python. Да, там есть чудеса и недоработки — но такого «коврового бомбометания» несуразностей как в PHP или JavaScript там никогда не было.

А какие «чудеса» не позволяют?

Ну тут беда не в JavaScript'е, а в DOM'е — но на практике от этого не легче. Много чего доступно через глобальные переменные.

В смысле? Несколько объектов (массив) в одном звене цепи наследования? А какая разница.

Большая разница: посмотрите на «классику жанра» — ios, iostream, ostream и iostream в C++.

И почему «тогда бы были доступы примеси»? Где точный алгоритм реализации примеси? Примесь может быть реализована и вклиниванием хидден-класса в цепь наследования и, так же, расширением самого объекта родными слотами.

Про примеси даже Wikipedia неплохо пишет. Хидден-классы их не реализуют ни разу (ещё раз на пример с ios/istream/ostream/iostream, пожалуйста), множественное наследование и множественные прототипы — реализуют запросто. Через расширение объекта родными слотами можно сделать вообще что угодно, но там придётся много наворотов (понятно что в динамических языках можно менять и istream и ostream и эти изменения сразу и непосредственно влияют на iostream).

Почему не означает? Реализаций — много, идей — еще больше. Как реализовали, ==, так, вероятно, и задумывалось.

Нет, увы. Реализовали — как левая пятка возжелала. Потом добавили NaN чтобы дыру заткнуть. Получился дурдом.

А покажите пример, эквивалентности объектов в разных языках. Мне интересно.

Классическая тройка эквивалентностей из Lisp'а не подойдёт? Все три оператора «eq?», «eqv?», «equal?» — полноценные операторы эквивалентности; «=», «char=?» и прочие — специализированные (в смысле: могут кинуть исключение, но на тех данных, на которых не кидают — являются операторами эквивалентности). «eq?», «eqv?», «equal?» как бы охватывают всё более и более общие случаи:
(eq? 1 1) => #t
(eq? 1234567890123456789012345678901234567890 1234567890123456789012345678901234567890) => #f
(eqv? 1234567890123456789012345678901234567890 1234567890123456789012345678901234567890) => #t
(eqv? '(1 2) '(1 2)) => #f
(equal? '(1 2) '(1 2)) => #t
(= 1 1) => #t
(= 1234567890123456789012345678901234567890 1234567890123456789012345678901234567890) => #t
(= '(1 2) '(1 2)) => ERROR
(char=? #\a #\a) => #t
(char=? #\a #\b) => #f
(char=? #\a '(1 2)) => ERROR

Всё просто и предсказуемо не нужно гадать на кофейной гуще (по модулю чисел с плавающей точкой — но они тоже на ровном месте не возникают, строка не может вдруг сама неожиданно преобразоваться куда-нибудь).