История изменений

Так это та самая ООБД, про которую ты только что писал, что ничуть не лучше, чем PostgreSQL.

Не совсем та самая.

LD — это всего лишь один из типов поддерживаемых контейнерами данных и, до кучи, легковесный формат нуль-сериализации а-ля capnproto. Мемория построена по data-oriented design и использует модель Structure-of-Arrays, который хорошо подходит для линейного поиска, но плохо — для pointer chasing. Вот специально для второго случая и сделан LD, потому что он обеспечивает О(1) для перехода по ссылкам для тех алгоритмов, для которых это критично. Например, для generic graph traversal.

Объекты не хранятся в LD-документах. Там внутри тоже DOD, в котором, в отличие от ООП, фиксируются не интерфейсы объектов, а схемы типизированных данных в заданной модели памяти. Под капотом, LD-enabled типы, — POD-состояния или TriviallyCopyable StandardLayout-состояния, для которых высокоуровневые объектные вьюшки создаются на лету, потому что так удобнее обращаться к хранимым данным из ООЯП. Ну и человеку тоже так во многих случаях удобнее.

Т.е. это все же не ООБД, так как ОО-уровень там создается динамически в момент обработки этих данных. А на уровне репрезентаций там все равно DOD.

В LD-документе нельзя сохранить произвольный объект С++. Полиморфные объекты там не поддерживаются вообще, а для остальных нужно отдельно определять state и view, и держать эти вещи согласованными через систему type traits. Последнее весьма геморно (TMP весьма плох в плане представления структур данных списками типов), и специально для этого я приделал к Мемории кодогенератор на основе библиотек Clang, который возьмет на себя низкоуровневую кодогенерацию по декларативным описаниям LD-типов данных.

Короче, если ты хочешь классификации, то это всё же не ООБД, так как хранятся не объекты, а их репрезентации. А объектные представления создаются «на лету» во время обращения к этим данным из ОО-кода. Т.е. это по сути легковесный DOD-OOP mapping.

Но для программиста всё в конечном итоге (с учетом наличия проектно-специфичного кодогенератора) может выглядеть как будто Мемория — это ООБД. Но «внутри» оно — нет)

Так это та самая ООБД, про которую ты только что писал, что ничуть не лучше, чем PostgreSQL.

Не совсем та самая.

LD — это всего лишь один из типов поддерживаемых контейнерами данных и, до кучи, легковесный формат нуль-сериализации а-ля capnproto. Мемория построена по data-oriented design и использует модель Structure-of-Arrays, который хорошо подходит для линейного поиска, но плохо — для pointer chasing. Вот специально для второго случая и сделан LD, потому что он обеспечивает О(1) для перехода по ссылкам для тех алгоритмов, для которых это критично. Например, для generic graph traversal.

Объекты не хранятся в LD-документах. Там внутри тоже DOD, в котором, в отличие от ООП, фиксируются не интерфейсы объектов, а схемы данных. Под капотом, LD-enabled типы, — POD-состояния или TriviallyCopyable StandardLayout-состояния, для которых высокоуровневые объектные вьюшки создаются на лету, потому что так удобнее обращаться к хранимым данным из ООЯП. Ну и человеку тоже так во многих случаях удобнее.

Т.е. это все же не ООБД, так как ОО-уровень там создается динамически в момент обработки этих данных. А на уровне репрезентаций там все равно DOD.

В LD-документе нельзя сохранить произвольный объект С++. Полиморфные объекты там не поддерживаются вообще, а для остальных нужно отдельно определять state и view, и держать эти вещи согласованными через систему type traits. Последнее весьма геморно (TMP весьма плох в плане представления структур данных списками типов), и специально для этого я приделал к Мемории кодогенератор на основе библиотек Clang, который возьмет на себя низкоуровневую кодогенерацию по декларативным описаниям LD-типов данных.

Короче, если ты хочешь классификации, то это всё же не ООБД, так как хранятся не объекты, а их репрезентации. А объектные представления создаются «на лету» во время обращения к этим данным из ОО-кода. Т.е. это по сути легковесный DOD-OOP mapping.

Но для программиста всё в конечном итоге (с учетом наличия проектно-специфичного кодогенератора) может выглядеть как будто Мемория — это ООБД. Но «внутри» оно — нет)

Так это та самая ООБД, про которую ты только что писал, что ничуть не лучше, чем PostgreSQL.

Не совсем та самая.

LD — это всего лишь один из типов поддерживаемых контейнерами данных и, до кучи, легковесный формат нуль-сериализации а-ля capnproto. Мемория построена по data-oriented design и использует модель Structure-of-Arrays, который хорошо подходит для линейного поиска, но плохо — для pointer chasing. Вот специально для второго случая и сделан LD, потому что он обеспечивает О(1) для перехода по ссылкам для тех алгоритмов, для которых это критично. Например, для generic graph traversal.

Объекты не хранятся в LD-документах. Там внутри тоже DOD, в котором, в отличие от ООП, фиксируются не интерфейсы объектов, а схемы данных. Под капотом, LD-enabled типы, — POD-состояния или TriviallyCopyable StandardLayout-состояния, для которых высокоуровневые объектные вьюшки создаются на лету, потому что так удобнее обращаться к хранимым данным из ООЯП. Ну и человеку тоже так во многих случаях удобнее.

Т.е. это все же не ООБД, так как ОО-уровень там создается динамически в момент обработки этих данных. А на уровне репрезентаций там все равно DOD.

В LD-документе нельзя сохранить произвольный объект С++. Полиморфные объекты там не поддерживаются вообще, а для остальных нужно отдельно определять state и view, и держать эти вещи согласованными через систему type traits. Последнее весьма геморно (TMP весьма плох в плане представления структур данных списками типов), и специально для этого я приделал к Мемории кодогенератор на основе библиотек Clang, который возьмет на себя низкоуровневую кодогенерацию по декларативным описаниям LD-типов данных.

Короче, если ты хочешь классификации, то это всё же не ООБД, так как хранятся не объекты, а их репрезентации. А объектные представления создаются «на лету» во время обращения к этим данным из ОО-кода. Т.е. это по сути легковесный DOD-OOP mapping.

Но для программиста всё в конечном итоге (с учетом наличия проектно-специфичного кодогенератора) может выглядеть как будто Мемория — это ООБД. Но нет)