Обязательность вызова super вообще - нет, обязательность вызова до записи в this - да. В стандарте сейчас пруф не смог найти, но дело в том, что объект создается в момент вызова самого глубокого конструктора в иерархии (чтобы, в частности, возможно было наследовать от встроенных классов, создающих экзотические объекты); соответственно, до вызова super (если он вообще есть) this попросту еще не существует.

не согласен. Объект создается в момент вызова конструктора верхнего уровня, и уже после этого на него применяются изменения вглубь дерева наследования (level_1 -> level_2 -> level_3) по средствам вызова super()

а то, о чем ты сказал делает цепочка прототипов

http://www.2ality.com/2015/02/es6-cl...structor_calls

http://www.2ality.com/2015/02/es6-cl...tanc e_object

Да, так что я попутал - не вызывать super в ребенке тоже нельзя.

---
Посредством. По средствам только живут.
Этому форуму жутко не хватает тега hr, да.

Erolast, можно подхачить.

---------------------------------------------------------------------------------

Типа линия.

UPD: Хотя на фуррифоксе говёно :с Как вариант -- поискать какой-нибудь неразрывный пробел, который местным парсером не вырезается.

Да я и сам не знаю(

Тогда уж проще сразу U+2500 (или толстый U+2501) из box-drawing characters задействовать, он позволяет нарисовать неразрывную черту:
────────────────

Правда, при длине > 16 гребаный форум почему-то превращает всё в кракозябры.

Вопрос к тем, кто работал с документно-ориентированными БД. В частности PouchDB

есть сущность в виде гномика объекта:

// contact
{
    "name": "string"
    "posts": [
        {
            "message": "string",
            "date": "string",
            "attachments": {
                "foo.txt": {
                    "type": "string",
                    "data": "base64"
                }
            }
        }
    ]
}

в которой будут размножаться контакты, посты, вложения. Как правильней всего хранить в бд?

1. Создать бд contacts и пихать туда контакты со всеми данными, но тогда при изменении контакта придется сохранять весь контакт. Правильно ли это?

2. Или создать базы contacts, posts и связать их по id? Но тогда это уже будет похоже на реляционную модель. :-?

2-й путь правильный, конечно.

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

Хороший путь, кстати -- это у контакта есть ID, а у поста есть поле, скажем, createdBy, в котором хранится значение ID контакта-создателя. Контакт ничего не знает о постах (это только информация о нем самом), посты знают ID того, кто их создал, но больше ничего о нем не знают.

Оговорюсь, что это актуально для монги, но, думаю, для этой базы тоже верно.

Правильней так, как говорит баланс. Всё зависит от количества обращений к записям и таблицам. Нужно нарисовать схему и посчитать количество запросов к БД и прикинуть нагрузку. Нагрузка будет либо на выборку из БД (обычно за это отвечает сама БД), либо на сервер (обработчик). Поэтому правильней выбирать БД под задачу. В остальном как написал trikadin.

и для остальных БД тоже не критично :)

trikadin, спасибо.

сервера не будет, все на клиенте