Как может выглядеть идиоматический дизайн Serializable / Cloneable / ... в Scala?

Question

Интересно, насколько отличались бы эти функциональные возможности (и насколько отличной была бы реализация), если бы Scala не следовала (не должна) следовать Java java.io.Serializable / java.lang.Cloneable (в основном, чтобы оставаться совместимой с Java и инструменты / экосистема вокруг него).

Поскольку Scala проще в проектировании языка, но обеспечивает более мощные возможности реализации и абстракции, вполне вероятно, что Scala может пойти по другому пути, чем Java, если бы не пришлось брать на себя бремя совместимости с Java.

Я мог бы представить, что идиоматическая реализация будет использовать классы типов или признаки с (возможно) закрытыми полями / методами (что невозможно в интерфейсах Java?), Возможно, с какой-то стандартной реализацией?

Или маркерные интерфейсы все еще являются правильным выбором в Scala?

Answer 1

Сериализация и клонирование являются особенными из-за изменчивости:

• Сериализация, потому что она имеет дело с циклами в графе объектов, и;
• Клонирование, потому что ... Ну, единственная причина клонирования объекта - это предотвращение случайного распространения изменчивого состояния.

Так что, если вы готовы перейти к полностью неизменной доменной модели, у вас больше нет графов объектов как таковых, вместо этого у вас есть деревья объектов.

Для функционально-ориентированного подхода к сериализации SBinary - это то, что я, вероятно, попробую первым. Для клонирования, просто не делай этого. :)

Answer 2

Или маркерные интерфейсы по-прежнему являются правильным выбором в Scala?Они даже не правильный выбор в Java.Они должны быть аннотациями, а не интерфейсами.

Answer 3

лучший способ сделать это в идеологической скале - это использовать имплициты с эффектом класса типов.Это используется для упорядоченного признака

def max[A <% Ordered[A]](a:A,b:A); 

означает то же самое, что и:

def max[A](a:A,b:A)(implicit orderer: T => Ordered[A]);

Это говорит о том, что вы можете использовать каждый тип A, если он может быть обработан как упорядоченный [A].это имеет несколько преимуществ, которых у вас нет с интерфейсом / наследованием Java

1. Вы можете добавить неявное упорядоченное определение к существующему типу.Вы не можете сделать это с наследованием.

2. Вы можете иметь несколько реализаций Ordered для одного Типа!Это даже более гибко, чем классы типов в Haskell, которые допускают только один экземпляр для каждого типа.

В заключение подразумевается, что значения скаляров, используемые вместе с обобщениями, дают очень гибкий подход для определения ограничений на типы.1019 *

То же самое и с cloneable / serializable.

Возможно, вы захотите взглянуть на библиотеку scalaz, которая добавляет классы типов haskell, такие как Functor, Applicative и Monad, и предлагает богатый наборподразумевает, что эта концепция также может обогатить стандартную библиотеку.