Что-бы избавиться от приведений типов при работе со списком, так как при наследовании в Оберонах нельзя нормально перекрыть методы предка (создать у потомка метод с тем-же именем, но другими типами параметров, например), можно только создать методы с другими именами. В итоге при наследовании получается венигрет из методов предка и новых методов, что не очень хорошо. Мы в этом случае лишаемся помощи компилятора в контроле типов, если случайно в коде используем не тот метод...
Цитата:
Если всё равно оборачивать базовые типы в запись, то почему нельзя было сразу сделать интерфейсную запись для списка ?
В смысле, делать внутренний массив типа этой записи? Конечно, тоже такое желание возникает, сэкономить память.
А с другой стороны... Допустим, есть у нас какие-то данные, представленные указателем на запись с десятком полей, и 2-3 структуры хранящие указатели на эти записи. Это надо, если есть необходимость отсортировать данные по разным полям, например. Фактически в этом случае имеем экономию памяти за счёт оперирования общими указателями между разными структурами.
Вот, бувально вчера реализацию алгоритма А* писал. Всё свелось к двум структурам: двоичной куче, построенной по одному полю и карте, отсортированной двум другим полям. В некоторых случаях, имея общий указатель, можно даже избежать вставки/удаления элементов!