Здравствуйте, deniok, Вы писали:

lse>>Хм, и в самом деле никакой. Только вот тут такой момент есть. Представим АТД, состоящий из двух друзей, у каждого из друзей есть копия машины вместо ссылки. Тогда при изменении цвета машины нужно будет создать новый экземпляр АТД, и не забыть установить цвет машины в двух местах — у каждого из друзей. А в случае ссылки достаточно было бы изменить цвет машины один раз в одном месте. Понятно конечно, что такой подход чреват побочными эффектами, но все же в этом отдельном случае ручками поменьше работать приходится. Я уже не говорю о том, что памяти в 2 раза больше нужно для хранения экземпляра такого АТД (хотя реализация может в самом деле попытаться оптимизировать это).

D>Это всё ООП-рассуждения. Что у тебя в предметной области-то, одна машина? Тогда тупл такой
D>

D>(Friend, Friend, Car)
D>

Одна машина, но она общая для обеих друзей. Если сделать, как у тебя выше, то нужно, чтобы функции (методы) Friend могли работать с Car. Поэтому нужно, чтобы Car был в каждом из них (копии Car), либо предавать Car из родителя при вызове функции, где этот Car требуется.

Скажем на псевдоязыке:

type Friend
{
    Car car;
    Car getCarColor = return getColor(car)
}

type Family
{
    Friend friend1;
    Friend friend2;
    
    Color getFamilyCarColor = getCarColor(friend1)
}

либо

type Friend
{
    Car getCarColor car = return getColor(car)
}

type Family
{
    Friend friend1;
    Friend friend2;
    Car car;
    
    Color getFamilyCarColor = getColor(car)
}

lse>>PS пример машинами и друзьями дурацкий, ибо такой АТД нафиг не нужен. Но вот с кажем, моделирование конкретного технического объекта — например, электрической схемы.

D>И что? Не поддаётся декларативному описанию?

Представь себе, нет. Декларативное описание суть дерево. А там такие бл-кие взаймосвязи между элементами схемы, без ссылок никак.