Чисто функциональные структуры данных с копией на записи?
Я думаю, что это основные отличия
- удобочитаемость кода
- управление тем, что является Вашим кодом, делающим
, Удобочитаемость может сделать код улучшенным или заняла место спустя 6 месяцев после того, как это было создано с litte усилием, с другой стороны, если производительность очень важна, что можно хотеть использовать низкоуровневый язык для предназначения для определенных аппаратных средств, которые Вы будете иметь в производстве, так для получения более быстрого выполнения.
IMO сегодня компьютеры достаточно быстры, чтобы позволить программисту получить быстрое выполнение с ООП.
2 ответа
Это звучит ужасно запутанно и подвержено ошибкам по сравнению с просто наличием полностью неизменяемой структуры данных и последующим использованием оболочки, которая содержит ссылку на нее и предоставляет императивный интерфейс, который работает путем обновления обернутой версии.
например, в Scala
class ImmutableData{
def doStuff(blah : Blah) : ImmutableData = implementation
}
class MutableData(var wrapped : ImmutableData){
def doStuff(blah : Blah) : Unit = { wrapped = wrapped.doStuff(blah); }
}
Конечно, это означает, что вам нужно создать две версии интерфейса, но семантика намного разумнее.
Функциональные («постоянные») структуры данных обычно рекурсивно создаются из неизменяемых узлов (например, односвязный список, в котором используются общие суффиксы, дерево поиска или куча, где только части необходимо скопировать древовидную структуру, которая находится на пути от корня к обновляемому элементу).
Плохо все, что требует копирования всего набора для каждой модификации. В таких случаях вы, как правило, накладываете небольшие «различия», которые проверяются (что требует дополнительного времени), с рекурсией к предыдущим версиям. Время от времени, когда различия становятся слишком большими, вы можете выполнить глубокое копирование / перестроение (так что амортизированная стоимость не так уж плоха).
Постоянные структуры данных могут иметь значительные накладные расходы, но если у вас есть очень эффективное распределение небольших объекты (JVM GC соответствует требованиям), они могут быть очень практичными - в лучшем случае, такими же быстрыми, как и изменяемый эквивалент, обеспечивая постоянство только за счет используемой памяти, которая может быть намного меньше, чем полная копия при каждом обновлении.
В зависимости от вашего языка , вы, вероятно, обнаружите, что синтаксис, который вы хотите, трудно реализовать без перегрузки оператора для присваивания. Lvalue (изменяемые ссылки) в C ++ определенно требуют непостоянной семантики.