Уточнение поля записи типа запись

[ilovb]

Возникла потребность уточнить тип поля в расширении записи:

Код: [Выделить]

MODULE test;
IMPORT JS;
TYPE
  r1 = RECORD
    a: INTEGER
  END;
  r2 = RECORD(r1)
    b: INTEGER
  END;
  r3 = RECORD
    r: r1
  END;
  r4 = RECORD(r3)
    r: r2 (* АХТУНГ! *)
  END;
BEGIN
END test.
Такое возможно вообще сделать?

ps Я правильно понимаю, что это невозможно из-за фиксированного смещения полей внутри записи? (т.е. расширенная запись тупо не влезет в отведенное предком место)

[valexey_u]

Возникла потребность уточнить тип поля в расширении записи:

Код: [Выделить]

MODULE test;
IMPORT JS;
TYPE
  r1 = RECORD
    a: INTEGER
  END;
  r2 = RECORD(r1)
    b: INTEGER
  END;
  r3 = RECORD
    r: r1
  END;
  r4 = RECORD(r3)
    r: r2 (* АХТУНГ! *)
  END;
BEGIN
END test.
Такое возможно вообще сделать?

ps Я правильно понимаю, что это невозможно из-за фиксированного смещения полей внутри записи? (т.е. расширенная запись тупо не влезет в отведенное предком место)

Насколько я понимаю, вообще не существует языка где такое возможно.

[valexey_u]

Точнее так - возможен язык где разрешение имен таково, что у потомка может быть ЕЩЕ ОДНО поле с названием совпадающим с полем предка. В этом случае r4 будет содержать и поле r с типом r1 и поле r с типом r2, это два разных поля, то есть две независимые переменные. Изменение одного поля никак не скажется на другом.

[vlad]

Возникла потребность уточнить тип поля в расширении записи:

Не поверишь. И такое я видел. Крайне запутывает.

Такое возможно вообще сделать?

Ну как обычно - через указательный тип.

ps Я правильно понимаю, что это невозможно из-за фиксированного смещения полей внутри записи? (т.е. расширенная запись тупо не влезет в отведенное предком место)

Да. Хотя в варианте oberonjs могло быть бы реализовано без проблем - там никаких смещений нет.

[ilovb]

Ну как обычно - через указательный тип.

Через указатель понятно что можно. Но это лишний объект в куче.
Вопрос именно в RECORD

[vlad]

Точнее так - возможен язык где разрешение имен таково, что у потомка может быть ЕЩЕ ОДНО поле с названием совпадающим с полем предка. В этом случае r4 будет содержать и поле r с типом r1 и поле r с типом r2, это два разных поля, то есть две независимые переменные. Изменение одного поля никак не скажется на другом.

Если все поля реализованы через указательные типы (как в oberonjs), то никто не мешает потомку расширить поле предка по все законам ООП.

[vlad]

Через указатель понятно что можно. Но это лишний объект в куче.
Вопрос именно в RECORD

Э... Ну в сях, конечно, можно без кучи Но лучше не надо

[valexey_u]

Точнее так - возможен язык где разрешение имен таково, что у потомка может быть ЕЩЕ ОДНО поле с названием совпадающим с полем предка. В этом случае r4 будет содержать и поле r с типом r1 и поле r с типом r2, это два разных поля, то есть две независимые переменные. Изменение одного поля никак не скажется на другом.

Если все поля реализованы через указательные типы (как в oberonjs), то никто не мешает потомку расширить поле предка по все законам ООП.

Ну ты же понимаешь что это ничем не будет отличаться от того же, но через указатель :-)

[vlad]

Ну ты же понимаешь что это ничем не будет отличаться от того же, но через указатель :-)

Реализация - да. Но семантически это будет поле-запись. Которое можно динамически проверить на принадлежность к расширенному типу (в обероне нельзя, вроде).

[Kemet]

Возникла потребность уточнить тип поля в расширении записи:

Зачем?
В своих типах, например в КП, можно использовать модификатор union, хотя это, естественно, не то. А так, нужно учитывать, что в твоём варианте мы должны поменять тип статического элемента, залезти в дескриптор типа вдажедьца, что явно приведет к проблемам.