Subtypes and Supertypes Setting the Scene

       

А почему не операции GET_ и SET_?


Как вы, должно быть, знаете, в подобных контекстах более принято говорить не в терминах THE_операций, как это делается в Манифесте, а в терминах операций GET_ и SET_. Например,

Z : = GET_X ( P ) ; /* получить в Z координату X точки P */

CALL SET_X ( P, Z ) ; /* установить в координату X точки P значение Z */

GET_ и SET_ - это примеры того, что в Манифесте называется операциями только чтения и обновления соответственно.

Почему же мы предпочитаем свои THE_операции более традиционным операциям GET_ и SET_? Ответ опирается на тот факт, что SET_операции являются обновляющими операциями, а в нашей нашей модели обновляющие операции не возвращают значений. Мы навязываем это правило, потому что не хотим допустить существования только читающих выражений, производящих побочные эффекты; в частности, мы не хотим допустить существования "простых выборок", обладающих побочным эффектом обновления базы данных! Однако из этого правила следует, что вызовы обновляющих операций не могут рассматриваться как скалярные выражения (поскольку у них нет значений) и, следовательно, они не могут вкладываться; вместо этого их необходимо считать операторами -- типично, CALL-операторами, как в примере.

Из того, что SET_операции не могут вкладываться, аналог с SET_операцией (например) для присваивания

THE_X ( THE_BEGIN ( LS ) ) : = Z ;

выглядел бы подобно следующему:

VAR TP POINT ;

TP : = GET_BEGIN ( LS ) ; /* делается копия точки начала */ CALL SET_X ( TP, Z ) ; /* эта копия соответствующим образом обновляется */ CALL SET_BEGIN ( LS, TP ) ; /* теперь обновляется точка начала */

Этот пример показывает, почему мы предпочитаем THE_псевдопеременные SET_операциям. Для симметрии мы предпочитаем THE_операции GET_операциям (хотя здесь стоило бы говорить о число синтаксических вопросах, а не о логическом отличии, поскольку GET_операции, в отличие от SET_операций, могут быть вложенными.



Содержание раздела