Quantcast

deprecate @serializable?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

deprecate @serializable?

Lukas Rytz
Hi,

  @serializable class X

is identical to

  class X extends Serializable

except for a small difference that most don't know and sometimes

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 really
want 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: deprecate @serializable?

Sam Stainsby-2
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)

-- Sam.

On Tue, 19 Oct 2010 15:28:54 +0200, Lukas Rytz wrote:

>   @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)


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: deprecate @serializable?

Erik Engbrecht
In reply to this post by Lukas Rytz
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.

On Tue, Oct 19, 2010 at 9:28 AM, Lukas Rytz <[hidden email]> wrote:
Hi,

  @serializable class X

is identical to

  class X extends Serializable

except for a small difference that most don't know and sometimes

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 really
want 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



--
http://erikengbrecht.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: deprecate @serializable?

Alex Hvostov
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

signature.asc (197 bytes) Download Attachment
Loading...