deprecate @serializable?

Arrrg, I was assuming they were identical. Sounds reasonable to deprecate
the annotation unless there is some added value in it hitherto
unmentioned.

( ... now to clean up some code)

Hi,
  @serializable class X
is identical to
  class X extends Serializable
except for a small difference that most don't know and sometimes bites people (http://lampsvn.epfl.ch/trac/scala/ticket/3924)
The reason is that the compiler converts the annotation only during type-checking, so depending on the order in which things type check,there might be an error message ("required: Serializable") or not.
The correct behavior would be to do the transformation earlier, but this is kind of a hack as some of you know (@BeanProperty), and we reallywant to avoid more annotations that influence typing.

If we remember correctly the annotation was added to have a uniform approach for JVM and .NET. But there would be another way to do that,something like
in Scala (JVM version)  package scala  trait Serializable extends java.lang.Serializable
in Scala.NET  package scala  trait Serializable

So we propose to deprecate the @serializable annotation.
Comments?
Lukas

On Tue, 2010-10-19 at 20:30 -0400, Erik Engbrecht wrote:
> I thought the purpose of @serializable was to enable proper generation
> of the serialVersionUid static final member of the class, because
> Scala doesn't have static fields.

No, that's what the @SerialVersionUID annotation (also in the scala
package) is for. You can even do this:

@SerialVersionUID(42)
class Foo extends java.io.Serializable

This does what it should, namely include a serialVersionUID field on
classOf[Foo].

If we're going to deprecate @serializable and introduce a trait
scala.Serializable, note that we still need @SerialVersionUID (instead
of an abstract val on scala.Serializable) because the serialVersionUID
field is *not* supposed to be inherited.

Alex