ОО-предписания
- В языке D должна допускаться проверка типов на стадии компиляции.
Комментарии:
- В этом предписании имеется в виду, что в той мере, в какой это осуществимо, следует выполнять проверку на стадии компиляции с тем, чтобы на стадии исполнения никакие ошибки типов не имели места. Это требование не исключает возможности "откомпилировать и исполнить" (compile and go), а также реализаций на основе интерпретации.
- (Простое наследование (Single Inheritance)) Если язык D позволяет определять некоторый домен V' как поддомен некоторого супердомена V, то такая возможность должна соответствовать некоторой ясно определенной и общепринятой модели.
Комментарии:
- Наша надежда заключается в том, что такая "ясно определенная и общепринятая" модель наследования когда-нибудь будет действительно найдена. Термин "общепринятая" призван здесь подчеркнуть, что авторы настоящего манифеста наряду с другими выступают в поддержку такой модели. От такой поддержки нет оснований отказываться.
- Отметим, что поддержка наследования подразумевает некоторые расширения определений скалярной переменной, кортежной переменной, отношения и relvar. Представляется также, что в этой связи потребуется, вероятно, несколько ослабить ОО-предписание 1. Набросок возможной модели наследования, которая бы интегрировала эти соображения, приводится в готовящемся к изданию приложении к данному манифесту (предварительную его версию можно получить в настоящее время у авторов).
- (Множественное наследование (Multiple Inheritance) Если в языке D допускается определение некоторого домена V' как поддомена какого-либо супердомена V, то не следует препятствовать также и тому, чтобы V' мог быть дополнительно определен как поддомен и некоторого другого супердомена W, который не совпадает с V и не является каким-либо его супердоменом (если только требования ОО-предписания 2 не исключают такую возможность).
- Язык D должен обладать вычислительной полнотой. Это означает, что D может (но не обязан) поддерживать вызовы из так называемых "основных программ" (host program), написанных на языках, отличных от D.
Подобным же образом, D может ( но не обязан) поддерживать использование других языков программирования для реализации функций, определяемых пользователем.
Комментарии:- Этим предписанием мы не намерены чрезмерно подрывать такую возможность, как оптимизируемость D. Мы не намерены также выдавать его за рецепт по использованию процедурных конструкций, подобных циклам, для выполнения запросов к базе данных или проверки целостности данных. Идея, скорее, состоит в том, что вычислительная полнота будет будет требоваться (в общем случае) для реализации функций, определяемых пользователем. Более удобно было бы иметь возможность реализовать такие функции в самом D, чем по необходимости совершать экскурсы в некоторые другие языки – экскурсы, которые в любом случае должны, по-видимому, порождать трудные проблемы для оптимизаторов. Мы, конечно, согласны с тем, что может оказаться желательным запретить использование некоторых возможностей D вне кода, который реализует такие функции. С другой стороны, такой запрет может слишком жестко ограничить то, что позволяет сделать "самостоятельная" прикладная программа (т.е. программа, которая не требует вызова из какой-либо программы, написанной на некотором другом языке). Эта проблема требует дополнительного изучения.
- Инициирование транзакции должно производиться только с помощью явного оператора "начать транзакцию" (start transaction). Завершение транзакции должно осуществляться только с помощью операторов "зафиксировать" (commit) или "откатить" (rollback). Оператор "зафиксировать" должен быть явным, в то время как оператор "откатить" может быть и неявным (в случае, когда транзакция завершается неудачно, хотя в самой транзакции не было никаких сбоев).
Комментарии:- Если транзакция T завершается оператором "зафиксировать" ("нормальное завершение"), то изменения, произведенные T в соответствующей dbvar, фиксируются. Если же транзакция T завершается оператором "откатить" (аварийное завершение), то изменения, произведенные T в соответствующей dbvar, анулируются.
Иными словами, dbvar ( и только они) обладают свойством "стабильности" ("persistence").
- Если транзакция T завершается оператором "зафиксировать" ("нормальное завершение"), то изменения, произведенные T в соответствующей dbvar, фиксируются. Если же транзакция T завершается оператором "откатить" (аварийное завершение), то изменения, произведенные T в соответствующей dbvar, анулируются.
- В языке D должны поддерживаться вложенные транзакции (nested transactions) – т.е. должно допускаться, чтобы какая-либо транзакция T1 могла начать другую транзакцию T2 до завершения собственного выполнения, и в этом случае:
- T2 и T1 должны взаимодействовать с одной и той же dbvar (как это фактически предусматривается РМ-предписанием16).
- D не должен препятствовать возможности асинхронного исполнения T1 и T2. Однако T1 не должна иметь возможности завершиться, прежде чем завершится T2 (иными словами, T2 должна полностью содержаться в T1).
- Откат T1 должен включать отмену результатов T2, даже если T2 была зафиксирована.
- Пусть A – некоторая агрегатная (aggregate) операция (например, операция вычисления суммы, SUM), которая, по существу, является просто краткой записью некоторой повторяемой диадической операции θ – (в случае SUM такой диадической операцией является "+"). Если аргумент A оказывается пустым, то:
- если для θ существует значение тождественности (в случае "+" значением тождественности является 0), то результатом такого вызова A должно быть это значение тождественности;
- в противном случае результат такого вызова A должен быть не определен.