Предыстория вопроса:
в tiscript/sciter встраивается persistence. Прямо в язык и рантайм.
Примерно это выглядит так:

Создание нового:

var storage = Storage.create(....);
    storage.root = { one: 1; two: 2; };
    storage.commit();

Использование существующего:

var storage = Storage.open(....);
var root = storage.root;

    stdout << root.one;
    stdout << root.two;

Я думаю идея понятна. Все терминальные типы int, string, float, etc. сохраняются прозрачно.
Также прозрачно сохраняются object, array и специальный тип коллекции index. Соответсвенно
и читаются (lazy reading)

Ну и теперь собственно философический вопросы:

1) к терминальным типам относятся также функции (внутри представлены как bytecode vector).
Технически несложно сохранять в storage и функции. Но что-то мне подсказывает что это будет
уже некая другая сущность а не storage. Как думаете?

2) если можно №1 то появляется возможность сохранять также классы (собственно они такие же объекты).
А это уже чего такое будет за storage?

Какие будут ваши мысли по теме?

Здравствуйте, c-smile, Вы писали:

А еще лучше персистить и данные, и функции, и типы с помощью единого механизма. Если не ошибаюсь, в Смоллтоке сделано именно так.
Кстати, а чем тебя не устраивает Смоллток?

Здравствуйте, c-smile, Вы писали:

CS>А это уже чего такое будет за storage?
Поправьте меня, но программисты 1С уже начиная с версии 7.5 использует storage для хранения своих конфигураций.
Сохраняются и формы и модули (с функциями) и описание данных. И ничего — называют они это метаданные.

Или я совсем не об этом?

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, c-smile, Вы писали:

Д>А еще лучше персистить и данные, и функции, и типы с помощью единого механизма. Если не ошибаюсь, в Смоллтоке сделано именно так.

Возникает вопрос:

Есть скажем модуль A в котором создается и используется storage.
Скажем в этом модуле также описаны некие классы.

Наступает завтра. Нам нужно поправить модуль A (код в этих самых классах).
Чего новому коду делать со старым который уже в DB сидит?

Д>Кстати, а чем тебя не устраивает Смоллток?

"Smalltalk люблю я но странною любовью".

Здравствуйте, c-smile, Вы писали:

CS>Есть скажем модуль A в котором создается и используется storage.
CS>Скажем в этом модуле также описаны некие классы.

CS>Наступает завтра. Нам нужно поправить модуль A (код в этих самых классах).
CS>Чего новому коду делать со старым который уже в DB сидит?

если нужно заботиться об обратной совместимости кода, можно хранить одновременно несколько версий класса, и биндить по имени+номер версии

Здравствуйте, c-smile, Вы писали:

CS>уже некая другая сущность а не storage. Как думаете?
...
CS>А это уже чего такое будет за storage?

В операционной системе Oberon в качестве storage для типов используются модули (module), и Object Library в качестве storage для персистентных объектов.

На сайте http://www.oberon2005.ru/ можно найти по этой теме следующие книги и статьи:

Project Oberon; Niklaus Wirth, Jurg Gutknecht;

Oberon with Gadgets A Simple Component Framework; Jurg Gutknecht, Michael Franz;

Oberon, Gadgets and Some Archetypal Aspects of Persistent Objects; Jurg Gutknecht;
и т.п.

Здравствуйте, c-smile, Вы писали:

CS>Есть скажем модуль A в котором создается и используется storage.
CS>Скажем в этом модуле также описаны некие классы.
Гм. У тебя все же есть классы? Не прототипы, как в javascript?
CS>Наступает завтра. Нам нужно поправить модуль A (код в этих самых классах).
CS>Чего новому коду делать со старым который уже в DB сидит?
Ну так это же два разных кода. Все как раз правильно — если хочется сконвертировать объекты в новую версию, надо сделать это руками.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, c-smile, Вы писали:

CS>>Есть скажем модуль A в котором создается и используется storage.
CS>>Скажем в этом модуле также описаны некие классы.

CS>>Наступает завтра. Нам нужно поправить модуль A (код в этих самых классах).
CS>>Чего новому коду делать со старым который уже в DB сидит?

Д>если нужно заботиться об обратной совместимости кода, можно хранить одновременно несколько версий класса, и биндить по имени+номер версии

А если не нужно?
А если и нужно то что A::func::v31 делать с A::func::v30 ?

Т.е. имеем зело философский вопрос.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, c-smile, Вы писали:

CS>>Есть скажем модуль A в котором создается и используется storage.
CS>>Скажем в этом модуле также описаны некие классы.
S>Гм. У тебя все же есть классы? Не прототипы, как в javascript?

Идея "объектов-вешалок" осталась ибо признана полезной для scripting use cases.
Но вся эта тягомотина с prototype — ушла.

Message =
{
  constructor  :function( text ) {  this.text = text;  },
  say           :function(  )     {  stdout.println( this.text );  }
}

FunnyMessage =
{
  prototype     :Message; // this is an extender of the Message.
  constructor  :function( text ) {  super("Funny:" + text);  },
  say           :function(  )     {  super.say();  }
}

var msg = new FunnyMessage("Hello World!");
msg.say(); // will print "Funny:Hello World!"

// these will evaluate to true:
msg.prototype === FunnyMessage;
msg instanceof FunnyMessage;

CS>>Наступает завтра. Нам нужно поправить модуль A (код в этих самых классах).
CS>>Чего новому коду делать со старым который уже в DB сидит?
S>Ну так это же два разных кода. Все как раз правильно — если хочется сконвертировать объекты в новую версию, надо сделать это руками.

Все больше я на это смотрю — все больше мне не нравится идея хранения кода в persistent storage.
Мухи отдельно — котлеты врозь.

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Здравствуйте, c-smile, Вы писали:

CS>>А это уже чего такое будет за storage?
N_C>Поправьте меня, но программисты 1С уже начиная с версии 7.5 использует storage для хранения своих конфигураций.
N_C>Сохраняются и формы и модули (с функциями) и описание данных. И ничего — называют они это метаданные.

N_C>Или я совсем не об этом?

Об этом. Вопрос только: это хорошо или плохо?
И что такое тогда компиляция? Как процесс выглядит?

В принципе если взять database какую никакую. Ну тот же Oracle например. Stored procedures есть сущность DB. Но в то же время допускается и Java код который живет уже отдельно.

Вот меня и интересует философская сторона этого дела. Данные это и процедуры тоже?

Здравствуйте, c-smile, Вы писали:

CS>А если не нужно?

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

CS>Об этом. Вопрос только: это хорошо или плохо?
Разницы особенной нет.

CS>И что такое тогда компиляция? Как процесс выглядит?
Также как и в обычной жизни. Только если обычно загружабт код с диска, то здесь из куска storage...
ИМХО что в лоб, что по лбу...

CS>В принципе если взять database какую никакую. Ну тот же Oracle например. Stored procedures есть сущность DB. Но в то же время допускается и Java код который живет уже отдельно.
Ага. А в SQL-2005 — .Net Framework код.

CS>Вот меня и интересует философская сторона этого дела. Данные это и процедуры тоже?
Хм. Когда я некоторым образом занимался оценкой трудоемкости сопровождения, где она рассчитывадась в зависимости от количества строк кода — мы считали, что это программы. По сути так оно и есть. Не важно где они хранятся. Хотя некоторые у нас для уменьшения стоимости сопровождения пытались представить метаданные, как обычные данные. Получается, что как кому удобно, так он и перекатывает.

PS
Кстати, не только 1С так хранит данные. По крайней мере Пермский "Прогноз" также хранит метеданные, правда в MS-SQL или Oracle...