Fwd: Why can I serialize scala.collection.immutable.List ?

On Wed, Jan 11, 2012 at 6:31 PM, Brian Maso <brian.d.maso@gmail.com> wrote:

(Forgot to send to scala-user)

---------- Forwarded message ----------
From: Brian Maso <brian.d.maso@gmail.com>
Date: 2012/1/11
Subject: Re: [scala-user] Why can I serialize scala.collection.immutable.List ?
To: √iktor Ҡlang <viktor.klang@gmail.com>




2012/1/11 √iktor Ҡlang <viktor.klang@gmail.com>

scala> List(1,2).isInstanceOf[Serializable]res0: Boolean = true

Yes, but

scala> implicitly[List[_] <:< java.io.Serializable]
<console>:8: error: Cannot prove that List[_] <:< java.io.Serializable.
              implicitly[List[_] <:< java.io.Serializable]

Which is odd considering

scala> implicitly[::[_] <:< java.io.Serializable]
res2: <:<[scala.collection.immutable.::[_],java.io.Serializable] = <function1>

I'm wondering why the base type wasn't declared Serializable, but instead the two subsclasses are. Just a little odd. Not a big deal.

I'm guessing because List, without known contents, is just a container. A box of Cheerios is edible, but I couldn't prove that if someone handled me a cereal box with mysterious contents, those contents would be edible.

List is sealed. So what would be the harm in marking it as Serializable?

On Wed, Jan 11, 2012 at 6:37 PM, Doug Tangren <d.tangren@gmail.com> wrote:

On Wed, Jan 11, 2012 at 6:31 PM, Brian Maso <brian.d.maso@gmail.com> wrote:

(Forgot to send to scala-user)

---------- Forwarded message ----------
From: Brian Maso <brian.d.maso@gmail.com>
Date: 2012/1/11
Subject: Re: [scala-user] Why can I serialize scala.collection.immutable.List ?
To: √iktor Ҡlang <viktor.klang@gmail.com>




2012/1/11 √iktor Ҡlang <viktor.klang@gmail.com>

scala> List(1,2).isInstanceOf[Serializable]res0: Boolean = true

Yes, but

scala> implicitly[List[_] <:< java.io.Serializable]
<console>:8: error: Cannot prove that List[_] <:< java.io.Serializable.
              implicitly[List[_] <:< java.io.Serializable]

Which is odd considering

scala> implicitly[::[_] <:< java.io.Serializable]
res2: <:<[scala.collection.immutable.::[_],java.io.Serializable] = <function1>

I'm wondering why the base type wasn't declared Serializable, but instead the two subsclasses are. Just a little odd. Not a big deal.

I'm guessing because List, without known contents, is just a container. A box of Cheerios is edible, but I couldn't prove that if someone handled me a cereal box with mysterious contents, those contents would be edible.

There would be no harm that I can see. The utility would be in documenting to people that it is safe to serialize lists.
Matthew

On 15 January 2012 08:45, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

List is sealed. So what would be the harm in marking it as Serializable?

On Wed, Jan 11, 2012 at 6:37 PM, Doug Tangren <d.tangren@gmail.com> wrote:

On Wed, Jan 11, 2012 at 6:31 PM, Brian Maso <brian.d.maso@gmail.com> wrote:

(Forgot to send to scala-user)

---------- Forwarded message ----------
From: Brian Maso <brian.d.maso@gmail.com>
Date: 2012/1/11
Subject: Re: [scala-user] Why can I serialize scala.collection.immutable.List ?
To: √iktor Ҡlang <viktor.klang@gmail.com>




2012/1/11 √iktor Ҡlang <viktor.klang@gmail.com>

scala> List(1,2).isInstanceOf[Serializable]res0: Boolean = true

Yes, but

scala> implicitly[List[_] <:< java.io.Serializable]
<console>:8: error: Cannot prove that List[_] <:< java.io.Serializable.
              implicitly[List[_] <:< java.io.Serializable]

Which is odd considering

scala> implicitly[::[_] <:< java.io.Serializable]
res2: <:<[scala.collection.immutable.::[_],java.io.Serializable] = <function1>

I'm wondering why the base type wasn't declared Serializable, but instead the two subsclasses are. Just a little odd. Not a big deal.

I'm guessing because List, without known contents, is just a container. A box of Cheerios is edible, but I couldn't prove that if someone handled me a cereal box with mysterious contents, those contents would be edible.

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

Interesting that:

scala.collection.immutable.List("1", "hi", Seq("dog","cat","frog"))

De-serializes to:

List(1, hi, List(dog, cat, frog))
class scala.collection.immutable.$colon$colon

I'm guessing this is related to Java type-erasure.

Am Montag, 16. Januar 2012 19:26:45 UTC+1 schrieb bryan hunt:

Interesting that:

scala.collection.immutable.List("1", "hi", Seq("dog","cat","frog"))

De-serializes to:

List(1, hi, List(dog, cat, frog))
class scala.collection.immutable.$colon$colon

I'm guessing this is related to Java type-erasure.

Nope, that’s just the actual classes which are created by the List() and Seq() factory methods.

Regards,

Roland

Seq is just a trait, the default concrete implementation of that trait is List.

On 16 January 2012 18:26, bryan hunt <sentimental.bryan@gmail.com> wrote:

Interesting that:

scala.collection.immutable.List("1", "hi", Seq("dog","cat","frog"))

De-serializes to:

List(1, hi, List(dog, cat, frog))
class scala.collection.immutable.$colon$colon

I'm guessing this is related to Java type-erasure.

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On Tue, 17 Jan 2012 13:08:22 +0000, Kevin Wright wrote:
Non-text part: multipart/alternative
> Seq is just a trait, the default concrete implementation of that trait is
> List.

Thanks Kev, clearest answer of the lot!

On Mon, Jan 16, 2012 at 7:16 AM, Matthew Pocock <turingatemyhamster@gmail.com> wrote:

There would be no harm that I can see. The utility would be in documenting to people that it is safe to serialize lists.
Matthew

This is precisely why having Serializable trait is a great harm: because it gives an impression that it is safe to serialize instances inheriting from it.

List can contain any members, even the ones that cannot be serialized, resulting in a non-serializable list instance. So not all instances of Serializable are in fact serializable. As a result, relying on Serialializable in method signatures will not save your from Serialization errors.

Serializable trait is Java has more to do with implimintation rather than indicating that an object can be serialized at the type level. I suspect this was one of the reasons Scala used @serializble annotation instead of extending Serializble trait (unfortunately this was changed in 2.9).

Worse, serializable classes can inherit from non-serializable traits. So having signatures like "def foo(s: Serializable)" will force users to cast "foo(x.asInstanceOf[Serializable])" without providing any safety against serialization errors. Instead you will be getting ClassCastException exceptions as well.

The decision to implement Seriazable as an interface in Java has been causing this confusion resulting in libraries that use Serializable in signatures. It is unfortunate that Scala has gave in to the pressure and changed it's serialiazble implementation from annotation to trait. My understanding this was done to be compatible with Java libraries using Serializable in method signatures, further propagating this confusion.

I should probably create a new thread for this question, so sue me...
In Python I can pickle a graph of Objects and just dump them to a file
somewhere for later retrieval.
What is currently considered the best way to do this?