11

I wonder how much different these funcionality would look like (and how different the implementation would be), if Scala wouldn't (have to) follow Java's java.io.Serializable/java.lang.Cloneable (mostly to stay compatible with Java and the tools/ecosystem around it).

Because Scala is more simpler in language design, but enables more powerful implementation and abstraction possibilities, it is thinkable that Scala might take a different path compared to Java, if it wouldn't have to shoulder the Java-compatibility-burden.

I could imagine that a idiomatic implementation would use type classes or traits with (possibly) private fields/methods (not possible in Java interfaces?), maybe carrying some standard implementation?

Or are marker interfaces still the right choice in Scala?

soc
  • 27,983
  • 20
  • 111
  • 215
  • One thing to note is that `case class`es are easily cloneable with their `copy` method, which also allows redefining some values while copying. – Jean-Philippe Pellet Jun 11 '11 at 21:07
  • cloneable and serializable in java are quite different, Object.clone() is just a memcpy (more or less) but serializing is full object graph traverse. – bestsss Jun 11 '11 at 21:52
  • Yes, I know that. The question is about these "magic" classes itself, I didn't want to imply that they are related. – soc Jun 11 '11 at 21:55

3 Answers3

4

Serialization and cloning are both kind of special because of mutability:

  • Serialization, because it has to deal with cycles in the object graph, and;
  • Cloning because... Well, the only reason to clone an object is to prevent the accidental spread of mutable state.

So, if you're willing to commit to a completely immutable domain model, you don't have object graphs as such anymore, you have object trees instead.

For a functionally-oriented approach to serialization, SBinary is what I'd probably try first. For cloning, Just Don't Do It. :)

Alex Cruise
  • 7,939
  • 1
  • 27
  • 40
2

Or are marker interfaces still the right choice in Scala?

Nope. They aren't even the right choice in Java. They should be annotations, not interfaces.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
  • 4
    But annotations don't get inherited right? Wouldn't that mean the annotation mechanism would have to replicate the language's inheritance rules? – soc Jun 12 '11 at 10:18
  • Also, as far as I know, annotations don't allow compile time checks such as `def foo(arg:Cloneable)` – fresskoma Jun 30 '11 at 07:58
  • @x3ro Not so. [cpsParam](http://www.scala-lang.org/api/current/index.html#scala.util.continuations.cpsParam) is a counter-example. I believe the annotation-specific type checking logic has to be implemented in a compiler plugin (or added to the typer), though. You can't just create an annotation that derives from [TypeConstraint](http://www.scala-lang.org/api/current/index.html#scala.annotation.TypeConstraint). – Aaron Novstrup Jul 01 '11 at 20:27
1

the best way to do this in ideomatic scala is to use implicits with the effect of a typeclass. This is used for the Ordered trait

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

means the same as: 

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

It says you can use every type A as long as it can be threated as an Ordered[A]. this has several benefits you don´t have with the interface/inheritance approach of Java

  1. You can add an implicit Ordered definition to an existing Type. You can´t do that with inheritance.

  2. You can have several implementation of Ordered for one Type! This is even more flexible than Type classes in Haskell wich allow only one instance per type.

In conclusion scalas implicits used together with generics enable a very flexible approach to define Constraints on types.

It is the same with cloneable/serializable.

You may also want to look at the scalaz library which adds haskell like typeclasses to Scala such as Functor, Applicative and Monad and offers a rich set of implicits so that this concepts can also enrich the standart library.

KIMA
  • 1,077
  • 6
  • 14
  • 1
    Downvoted: you are mixing up view bounds and context bounds, and `Ordered` with `Ordering`. Please read this and update your answer: http://stackoverflow.com/questions/4465948/context-and-view-bounds-again/4467012#4467012. Moreover, you don't discuss the more specific problems with cloning and serialization, such as inheritance and reusing the cloning and serialization capabilities of a superclass, etc. – Jean-Philippe Pellet Jun 11 '11 at 20:56