[прототипное ООП] WTF?

ссылку на вайтпэйпер кто давать будет?

Я по статье в вики (http://en.wikipedia.org/wiki/Prototype-based_programming) и докам по js изучал. В общем понятно почему js-ники все равно изобретают классы в своем прототипном царстве.

Прототипное ООП == «в нашем говноязыке нет классов, но зато мы помним SICP и сделаем всё на замыканиях»?

Создание объектов клонированием. Отлично. В обычном классовом ООП начальное состояние объекта определяется логикой конструктора. А тут состоянием объекта-прототипа в момент клонирования. Даешь сайд-эффекты в массы.

смотрим в статью:

In prototype-based systems, there are two methods of constructing new objects: ex nihilo («from nothing») object creation or through cloning an existing object.

man constructor, copy constructor

Таким образом состояние объекта с точки зрения клиентов зависит еще и от состояния прототипов данного объекта.

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

А this внутри функции вообще зависит от контекста вызова этой функции, шок? :D

>прототипное ООП

WTF?

Всё правильно понял.

Ви таки за Dart?

Прототипное ООП - бритва Оккама в чистом виде. Классы не нужны, ибо class is object, object is class

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

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

это такой спорт. кто лучше ооп сделает в js :/ Вот тут например попытка реальных приватов через 2 прототипа http://pastie.org/2689208

Не ну я не против того, что бы не иметь классов, но иметь объект-фабрику. Это дает хоть какой-то детерминизм.

Как я понял это лагерь ультра-минималистов, где ООП слеплено из объектов, у которых есть слоты, которые могут быть как обычными значениями, так и функциями и другими объектами и волшебным слотом-прототипом.

на практике же никто содержимое прототипов не меняет ну или меняет но не методы. погано то что приочепятке тебя компилятор не поправит. undefined получите распишитесь. если метод undefined то впринципе получишь ошибку а если не свойство то this.fo0++ даст NaN

1. Создание объектов клонированием. Отлично. В обычном классовом ООП начальное состояние объекта определяется логикой конструктора. А тут состоянием объекта-прототипа в момент клонирования. Даешь сайд-эффекты в массы.

То же, что и с классами, только взгляд со стороны :) У классов есть статические члены, и они одни для всех объектов, прям как поля прототипа. Если так уж нужно скрыть прототип от «не тех рук» - man замыкания.

PS. И да, в прототипном ООП тоже есть понятие конструктора.

В прототипном ООП же у общего прототипа может быть много наследников.

И у класса тоже. В чём проблема?

У классов есть статические члены, и они одни для всех объектов, прям как поля прототипа.

За мутабельные статические поля в классическом ООП принято ломать руки. Спасибо за меткую аналогию :)

В том, что объект-прототип имеет состояние, а базовый класс не имеет. Конечно, тут уже написали про статические поля класса. И все знают про их опасность. Тут мне уже написали, что хорошей практикой является не изменять объект-прототип. Что как бе намекает на ущербность прототипного ООП. Лучше что с ним можно сделать - это слепить классы.

> В том, что объект-прототип имеет состояние, а базовый класс не имеет

o'realy?

var foo = {name: "foo", one: 1, two: 2};
var bar = {three: 3};
bar.__proto__ = foo;
bar.name = "bar";
foo.name = "jazz";
console.log(bar);
=> Object { three=3, name="bar", one=1, two=2 ...}

А ту страшилку, что ты имеешь в виду - она надумана и не является проблемой в реальном коде.

Что как бе намекает на ущербность прототипного ООП.

В той же мере, в какой наличие статических полей намекает на ущербность классового ООП.

Лучше что с ним можно сделать - это слепить классы.

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

В той же мере, в какой наличие статических полей намекает на ущербность классового ООП

Не в той же. Статические поля это опциональная хрень, нарямую к классовому ООП не имеющая отношения. А делегирование это один из базовых механизмов прототипного ООП.

Угу, ну это понятно. Вообще по моему опыту на практике стерпеть можно что угодно: и ручное управление памятью, и public модификатор у всех полей (в питоне например), и так далее.

Статические поля это опциональная хрень, нарямую к классовому ООП не имеющая отношения.

Тем не менее, в C++ есть, в Смолтоке есть, и вообще, считай, везде есть.

А делегирование это один из базовых механизмов прототипного ООП.

Дашь денег — сделаю тебе язык с прототипным ООП, но без делегирования.

Тебе выше посоветовали, не лезь со своим уставом в монастырь, а попробовать без всей этой чепухи в голове про сайд-эффекты изучить язык.

В js не всё так страшно, как ты думаешь. Если в наследнике присваиваешь значение полю унаследованного от базового объекта, то дальнейшее изменение этого поля в базовом объекте не меняет это поле в наследнике, а большего и не требуется, чтобы не было хаоса.

>прототипное ООП

не нужно

</thread>