Обсуждений тред

[Erolast]

2. Разве это прописано в стандарте? Под "это" подразумеваю:
- обязательность вызова супер в ребенке в принципе
- обязательность вызова супер до работы с this в ребенке

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

[nerv_]

что объект создается в момент вызова самого глубокого конструктора в иерархии

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

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

[Erolast]

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

In a derived class, you must call super() before you can use this.
Implicitly leaving a derived constructor without calling super() also causes an error.

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

In ES6, it [an instance] is created in the base constructor, the last in a chain of constructor calls.

this originally being uninitialized in derived constructors means that an error is thrown if they access this in any way before they have called super().

If a constructor returns implicitly (without a return statement), the result is this. If this is uninitialized, a ReferenceError is thrown. This protects you against forgetting to call super().

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

---

по средствам

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

[trikadin]

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

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

Типа линия.

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

[Safort]

Ну не перешли они и бог с ними. Как это мешает использованию бабеля?

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

[Erolast]

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

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

Типа линия.

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

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

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

[nerv_]

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

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

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

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

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

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

[trikadin]

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

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

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

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

[MakeMeFeel]

Как правильней всего хранить в бд?

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

это актуально для монги

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

[nerv_]

trikadin, спасибо.

либо на сервер

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