Коньцепция

[metaclass]

А вот скажите, существует ли где-нибудь в академических эмпиреях компутер сайенс такая вещь, как эволюционирующие типы?

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

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

Comments

[theiced.livejournal.com]

Ну чо - мастер функа, которая в зависимости от фазы луны вызывает нужный вариант (грубо). Как реализовать - в зависимости от платформы. Будь то элегантное решение в лиспах или там жабские аспекты или кошмар с `class RasschetProvodokSTretjeyFazyLunyPoChetvertuju17800GodaEraOpezdola` с мастер классом.

С данными вот сложнее. Если идёт ввод `задним числом` то надо дёрнуть все последующие `конвертации`. Если данные непротиворечивы - то всё просто, а если противоречивы - то две копии хранить, хуле.

[theiced.livejournal.com]

И да - счастье если юзеры спят по ночам. А вот если остановка системы на 5 минут == куча геммора и согласовний - то пиздец совсем.

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

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