Object cloning in Scala

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).   When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.
In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Mon, Aug 23, 2010 at 05:29:21PM +0200, iulian dragos wrote:
> My current stance is that Scala should protect its abstractions, and
> since an object is supposed to have exactly one instance, cloning
> should be disallowed.

That was my feeling too.

> This method is not added if the object does not derive from
> java.lang.Cloneable. If the object has a user-defined clone operation,
> the compiler emits a warning, but does not fail:
>
> test-object-clone.scala:21: warning: Scala objects should not be cloned.
> override def clone = super.clone
> ^

Even this seems like a generous compromise! But it sounds pretty
reasonable to me (and like you I am not sure I'm not missing some more
convincing motivation.) There might be a "warning annoyance zone" if
someone is inheriting from a class marked Cloneable, which maybe they
can't change, and wants to create a bunch of case objects. But that's
more of a "we need better control over warnings" issue.

I'm with Josh for non top-level objects. Consider:
scala> class A extends Cloneable { var foo: Int = 0; def copy = clone }                                          defined class A
scala> def bar(x: Int): A = { object Inner extends A { foo = x }; Inner }    bar: (x: Int)A
scala> val a = bar(7)a: A = Inner$2$@7e54864c
scala> val b = bar(8)b: A = Inner$2$@757ecdf0
scala> val c = b.copyc: A = Inner$2$@575887db
a, b, c are distinct objects whose foo fields can be independently mutated.
what is gained by prohibiting the clone operation here?
- Tiark

On Aug 23, 2010, at 5:38 PM, Josh Suereth wrote:

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).   When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.
In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Mon, Aug 23, 2010 at 06:09:10PM +0200, Tiark Rompf wrote:
> I'm with Josh for non top-level objects.

So as long as non top level objects are suddenly on the brain...

Am I the only one driven into paroxysms of hair pulling by the subtle
and not-so-subtle differences between member objects and lazy vals? The
huge not-so-subtle one is that you can't override objects in subclasses.
This has a major impact on code reuse or the lack thereof in places like
Global which have whole football teams of objects.

Is there some distinction between them which is both intentional and
useful? If there is not, is there a path to unification?

The question is not entirely tangential to the current question because
I could imagine one answer involving objects (trying to) preserve the
singleton property. But if not that, then what?

On Mon, Aug 23, 2010 at 5:38 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).  

Can you please expand a bit on this point? I don't immediately see the connection between serialization and cloning. Serialization should not be affected by my proposed change.

When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.

That's already the way it works now. iulian

In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Mon, Aug 23, 2010 at 6:09 PM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:

I'm with Josh for non top-level objects. Consider:
scala> class A extends Cloneable { var foo: Int = 0; def copy = clone }                                           defined class A
scala> def bar(x: Int): A = { object Inner extends A { foo = x }; Inner }    bar: (x: Int)A
scala> val a = bar(7)a: A = Inner$2$@7e54864c
scala> val b = bar(8)b: A = Inner$2$@757ecdf0
scala> val c = b.copyc: A = Inner$2$@575887db
a, b, c are distinct objects whose foo fields can be independently mutated.
what is gained by prohibiting the clone operation here?

the question should be what is gained by allowing it? It is at least as succinct to define a val or a lazy val. 
By having objects have true singleton semantics, I see a gain in uniformity (top level objects and inner objects are treated the same way) and clarity: objects have exactly one instance. Note that we're trying hard now to ensure that objects are thread-safe, so it seems a pretty obvious hole to fill.
Even more, ticket 3764 shows that the compiler relies on this assumption. That's only one case, maybe there are more places like that. In short, closures don't capture objects as part of their environment, because they are 'global'. And in most cases they are, but if we support cloning, we'd need to capture them too, wasting some memory.
iulian 

- Tiark

On Aug 23, 2010, at 5:38 PM, Josh Suereth wrote:

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).   When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.
In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

My understanding is that 'inner' objects aren't singletons because they may need to close over their environment (see bar(7) and bar(8) below, those are clearly two different instances). If the goal is to give all objects true singleton semantics, then prohibiting clone is not sufficient because you can still end up with multiple instances in other ways. Looking at the ticket again though, it seems like only copies within the same scope pose problems. If clone is the only way to end up in such a situation then it might indeed be good to prohibit clone.- Tiark

On Aug 24, 2010, at 11:22 AM, iulian dragos wrote:

On Mon, Aug 23, 2010 at 6:09 PM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:

I'm with Josh for non top-level objects. Consider:
scala> class A extends Cloneable { var foo: Int = 0; def copy = clone }                                           defined class A
scala> def bar(x: Int): A = { object Inner extends A { foo = x }; Inner }    bar: (x: Int)A
scala> val a = bar(7)a: A = Inner$2$@7e54864c
scala> val b = bar(8)b: A = Inner$2$@757ecdf0
scala> val c = b.copyc: A = Inner$2$@575887db
a, b, c are distinct objects whose foo fields can be independently mutated.
what is gained by prohibiting the clone operation here?

the question should be what is gained by allowing it? It is at least as succinct to define a val or a lazy val. 

By having objects have true singleton semantics, I see a gain in uniformity (top level objects and inner objects are treated the same way) and clarity: objects have exactly one instance. Note that we're trying hard now to ensure that objects are thread-safe, so it seems a pretty obvious hole to fill.
Even more, ticket 3764 shows that the compiler relies on this assumption. That's only one case, maybe there are more places like that. In short, closures don't capture objects as part of their environment, because they are 'global'. And in most cases they are, but if we support cloning, we'd need to capture them too, wasting some memory.
iulian 

- Tiark

On Aug 23, 2010, at 5:38 PM, Josh Suereth wrote:

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).   When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.
In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Sorry, the serialization deal was an example, and I failed to illustrate my point.   Thinking of serialization as sending the state of a few objects over some medium, we see that this medium could be time.   i.e.  I would like to save my current state and restore it at some future date.   Having the ability to do so is important.   Some of these use cases actually can make use of clone instead, and I see the nested context as being important.
One of my original assumption was that I could use projections to access the type of B:  A#B.type.   This seems is 100% false, and you need the complete path dependent type to access B's type for assignment.   Therefore I'm less against the idea of object not being able to be cloned. I do still have one objection:
If I have class A { object B { var state : C } }, if I want to clone A, then I necessarily need to clone C correct?   If B disallows cloning, how am I able to clone A?   If there's something I'm not seeing, let me know because this nesting is the only reason I think objects should support cloning.

Also, for Tiark's use case above,  I think "object" is a greatly simplified concept if it is considered a "singleton in its current scope"  i.e. within the current method or within the current trait/class/object.  It can greatly reduce complexity.   I think outer-level modules are the "special case" of requiring JVM magic to construct them globally and threadsafe while ensuring they are singletons.    As for inner level objects, I can use them to capture the current variables in scope, as Tiark showed.  In fact, I like this encoding of nested object usages:
class A { object B }  ->    class A {   class `B$class`;  final val B = new `B$class` }
And:scala> val y : x.B.type = x.By: x.B.type = A$B$@316becfe
scala> def foo(a : Int) = {     | class `A$Class` {     | val x = a     | }     | new `A$Class`     | }foo: (a: Int)java.lang.Object with ScalaObject{def x: Int}
scala> foo(5)res0: java.lang.Object with ScalaObject{def x: Int} = A$Class$1@54861a09
scala> foo(5).x  res1: Int = 5

Sorry if I was confusing earlier!  I'll make sure to drink my coffee before responding in the future ;)
- Josh
On Tue, Aug 24, 2010 at 5:22 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

On Mon, Aug 23, 2010 at 6:09 PM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:

I'm with Josh for non top-level objects. Consider:
scala> class A extends Cloneable { var foo: Int = 0; def copy = clone }                                           defined class A
scala> def bar(x: Int): A = { object Inner extends A { foo = x }; Inner }    bar: (x: Int)A
scala> val a = bar(7)a: A = Inner$2$@7e54864c
scala> val b = bar(8)b: A = Inner$2$@757ecdf0
scala> val c = b.copyc: A = Inner$2$@575887db
a, b, c are distinct objects whose foo fields can be independently mutated.
what is gained by prohibiting the clone operation here?

the question should be what is gained by allowing it? It is at least as succinct to define a val or a lazy val. 
By having objects have true singleton semantics, I see a gain in uniformity (top level objects and inner objects are treated the same way) and clarity: objects have exactly one instance. Note that we're trying hard now to ensure that objects are thread-safe, so it seems a pretty obvious hole to fill.
Even more, ticket 3764 shows that the compiler relies on this assumption. That's only one case, maybe there are more places like that. In short, closures don't capture objects as part of their environment, because they are 'global'. And in most cases they are, but if we support cloning, we'd need to capture them too, wasting some memory.
iulian 

- Tiark

On Aug 23, 2010, at 5:38 PM, Josh Suereth wrote:

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).   When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.
In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Mon, Aug 23, 2010 at 9:31 AM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Aug 23, 2010 at 06:09:10PM +0200, Tiark Rompf wrote:
> I'm with Josh for non top-level objects.

So as long as non top level objects are suddenly on the brain...

Am I the only one driven into paroxysms of hair pulling by the subtle
and not-so-subtle differences between member objects and lazy vals? The
huge not-so-subtle one is that you can't override objects in subclasses.

Yeah... this is a *huge* problem in Lift-land... one that was supposed to be addressed in 2.6... but... well...
Anyway... supporting subclassing inner objects would be a tremendously huge win. 

This has a major impact on code reuse or the lack thereof in places like
Global which have whole football teams of objects.

Is there some distinction between them which is both intentional and
useful? If there is not, is there a path to unification?

The question is not entirely tangential to the current question because
I could imagine one answer involving objects (trying to) preserve the
singleton property.  But if not that, then what?

--
Paul Phillips      | A Sunday school is a prison in which children do
Vivid              | penance for the evil conscience of their parents.
Empiricist         |     -- H. L. Mencken
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

On Tue, Aug 24, 2010 at 2:39 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

..If I have class A { object B { var state : C } }, if I want to clone A, then I necessarily need to clone C correct?   If B disallows cloning, how am I able to clone A?   If there's something I'm not seeing, let me know because this nesting is the only reason I think objects should support cloning.

That's a good point. Note that Java cloning is always shallow, so you'll get a cloned A with a pointer to the old a.B. Even if B allowed cloning and you decided to implement your own, deep cloning, you wouldn't be much better. There is no way to assign a new value for the object B (at least, not without using the $-mangled name of the field that stores B). So if you want to clone, you should stay away from objects.  

Also, for Tiark's use case above,  I think "object" is a greatly simplified concept if it is considered a "singleton in its current scope"  i.e. within the current method or within the current trait/class/object.  It can greatly reduce complexity.   I think outer-level modules are the "special case" of requiring JVM magic to construct them globally and threadsafe while ensuring they are singletons.    As for inner level objects, I can use them to capture the current variables in scope, as Tiark showed.  In fact, I like this encoding of nested object usages:
class A { object B }  ->    class A {   class `B$class`;  final val B = new `B$class` }

That's more or less what they are. I'm sorry if my mail was unclear. Objects are indeed singleton with respect to their scope, so inner objects are unique only with respect to their enclosing instance.
However, the whole approach is invalid, as we discovered during a discussion with Evgueny Vigdorchik. One can write his own cloning method and call super.clone:
class Base extends Cloneable {   def clone = super.clone.asInstanceOf[Base]}
object Evil extends Base {  def myDeepClone = super.clone
  def clone = throw new CloneNotSupportedException // compiler-generated, but useless } There's no way to forbid that, so it's probably better to leave it as is.
iulian

And:scala> val y : x.B.type = x.By: x.B.type = A$B$@316becfe
scala> def foo(a : Int) = {     | class `A$Class` {     | val x = a     | }     | new `A$Class`     | }foo: (a: Int)java.lang.Object with ScalaObject{def x: Int}
scala> foo(5)res0: java.lang.Object with ScalaObject{def x: Int} = A$Class$1@54861a09
scala> foo(5).x  res1: Int = 5

Sorry if I was confusing earlier!  I'll make sure to drink my coffee before responding in the future ;)
- Josh
On Tue, Aug 24, 2010 at 5:22 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

On Mon, Aug 23, 2010 at 6:09 PM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:

I'm with Josh for non top-level objects. Consider:
scala> class A extends Cloneable { var foo: Int = 0; def copy = clone }                                           defined class A
scala> def bar(x: Int): A = { object Inner extends A { foo = x }; Inner }    bar: (x: Int)A
scala> val a = bar(7)a: A = Inner$2$@7e54864c
scala> val b = bar(8)b: A = Inner$2$@757ecdf0
scala> val c = b.copyc: A = Inner$2$@575887db
a, b, c are distinct objects whose foo fields can be independently mutated.
what is gained by prohibiting the clone operation here?

the question should be what is gained by allowing it? It is at least as succinct to define a val or a lazy val. 
By having objects have true singleton semantics, I see a gain in uniformity (top level objects and inner objects are treated the same way) and clarity: objects have exactly one instance. Note that we're trying hard now to ensure that objects are thread-safe, so it seems a pretty obvious hole to fill.
Even more, ticket 3764 shows that the compiler relies on this assumption. That's only one case, maybe there are more places like that. In short, closures don't capture objects as part of their environment, because they are 'global'. And in most cases they are, but if we support cloning, we'd need to capture them too, wasting some memory.
iulian 

- Tiark

On Aug 23, 2010, at 5:38 PM, Josh Suereth wrote:

I disagree about cloning objects.   If the object is in some context (i.e. it is a member of a particular class), then to serialize that context one must also serialize the object (i.e. to serialize an instance of the class, one needs to serialize the object).   When it comes to "module" like objects, then I agree.   Serialization seems funny here, but could be used to save/restore global state, so perhaps it is also something to support.   However, restoring the object should just reset the state on the instance of the global.  You cannot create another instance, just save/restore its state.
In terms of the automatic support for issuing a warning when a user defines a clone operation without @cloneable +1.
- Josh

On Mon, Aug 23, 2010 at 11:29 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

I would like to get some input on the issue of cloning (in the sense of java.lang.Cloneable) scala objects. This is the object of ticket 3764.
My current stance is that Scala should protect its abstractions, and since an object is supposed to have exactly one instance, cloning should be disallowed. However, I might be missing some important aspect, so I would like to get some feedback.
My proposal is that each scala object that subclasses Cloneable (or is annotated with @cloneable) gets a synthetic clone method like this:
override def clone =    throw new CloneNotSupportedException()
This method is not added if the object does not derive from java.lang.Cloneable. If the object has a user-defined clone operation, the compiler emits a warning, but does not fail:
test-object-clone.scala:21: warning: Scala objects should not be cloned.  override def clone = super.clone                ^Any thoughts?iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais