Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

Неа. Они даже не являются правильным выбором на Java. Они должны быть аннотациями, а не интерфейсами.

Ответ 3

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

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

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

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

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

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

  • У вас может быть несколько вариантов выполнения заказа для одного типа! Это еще более гибко, чем классы классов в Haskell, которые позволяют использовать только один экземпляр для каждого типа.

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

Это то же самое с клонируемым/сериализуемым.

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