java.lang.Cloneable deprecated? when?

[here]

They've been talking about it for years. Should be spelled Clonable.
Will it ever happen? Just curious.

 

[Lew]

They've been talking about it for years.

Who has?

Should be spelled Clonable.

Should it? Should it really?

The word is spelled with the "e" in English, why not in Java?

<http://blogs.bio.brandeis.edu/?p=238>
"Beth Stroupe and coworkers show that the use of the actin-nucleating
protein Spire as a cloneable tag allows them to nucleate actin
filaments"

<http://www.bio-medicine.org/biology-technology/Get-the-5-End-1003-1/>
"Statistically, the further towards the 5'-end a sequence lies, the
less likely a successful priming event will occur upstream from that
end to make the region double-stranded and cloneable."

<http://genomebiology.com/2007/8/4/R45>
"Directional cloneable cDNA was synthesized from 5 ìg Poly(A+) mRNA
using the cDNA Synthesis Kit (Stratagene, Cedar Creek, USA) following
the manufacturer's protocol."

<http://books.google.com/books?
id=CpBGrwbIYgQC&pg=PA9&lpg=PA9&dq=cloneable
+biology&source=bl&ots=pcLKx7Wj41&sig=twzRJ13140JzjP6fQZO72AZ5nZk&hl=en&sa=X&oi=book_result&resnum=10&ct=result#PPA9,M1>

<http://www.docstoc.com/docs/1025993/Genome-sequence-of-the-Brown-
Norway-rat-yields-insights-into-mammalian-evolution>
"For the rat genome, the assembled and cloneable genome sizes are very
close ..."

<http://www.informaworld.com/smpp/content~content=a791398120~db=all>
"... the sequences concerned are "fragile" and easily denatured,
commonly uncloneable and have a paucity of good oligonucleotide
priming sites."

Will it ever happen?

No.

Never say never, but the chances of rewriting the specification and
implementation of java.lang.Object to accommodate a putatively
incorrect spelling of a class name that is actually not incorrect are
negligible.

 

[Mark Space]

They've been talking about it for years. Should be spelled Clonable.
Will it ever happen? Just curious.

The problem with Cloneable is that it doesn't export any public methods,
it's just a "mix-in" type. Cloneable would be better if it guaranteed
that the implementing class supported a public clone() method.

It would be even better if Cloneable dictated some sort of semantics,
like a deep copy. Sadly some API classes explicitly support a shallow
copy with clone() (like List).

 

[Lew]

The problem with Cloneable is that it doesn't export any public methods,
it's just a "mix-in" type.  Cloneable would be better if it guaranteed
that the implementing class supported a public clone() method.

Since 'clone()' is a method of the primordial 'Object' type, having it
as part of the 'Cloneable' interface would not do much. You would
always at least trivially implement the interface, and could not
prevent failure to adhere to a deep-copy semantic. Having the
primordial 'clone()' check for that marker interface and thrown an
Exception in the face of its absence is an evil hack, though.

I guess the reason to have it in 'Object' and not implemented solely
by implementors of 'Cloneable' is to provide the primordial
implementation from the very top. Otherwise a class that did
implement 'Cloneable' would not be able to do so, because none of its
ancestor type information would clone.

 

[Mike Schilling]

Since 'clone()' is a method of the primordial 'Object' type, having
it
as part of the 'Cloneable' interface would not do much. You would
always at least trivially implement the interface, and could not
prevent failure to adhere to a deep-copy semantic. Having the
primordial 'clone()' check for that marker interface and thrown an
Exception in the face of its absence is an evil hack, though.

I guess the reason to have it in 'Object' and not implemented solely
by implementors of 'Cloneable' is to provide the primordial
implementation from the very top. Otherwise a class that did
implement 'Cloneable' would not be able to do so, because none of
its
ancestor type information would clone.

It would have made more sense for

1. Cloneable to define public clone(), and
2. the protected primordial method to have a name other than clone()

I think that gives he same ability to enable or disable cloning as you
like, and isn't as difficult to explain .

 

[Mark Space]

It would have made more sense for

1. Cloneable to define public clone(), and
2. the protected primordial method to have a name other than clone()

I think that gives he same ability to enable or disable cloning as you
like, and isn't as difficult to explain .

I think

public class Object {
protected Object clone() { ... }
}

public interface Cloneable {
public Object clone() {}
}

would work just fine. I don't know if it's always been possible to make
a method more accessible than the one it inherits from, so perhaps
that's the reason why Cloneable works the way it does. Otherwise, I
just assume it's an "oops" in the API. Those things do happen.

Just to clarify, the following is at least syntactically correct, even
though it will in fact throw an error. But that's only because the
illustration I use doesn't actually implement Cloneable, just my own
version of it.


interface myCloneable
{
Object clone();
}

class Test implements myCloneable
{
@Override
public Object clone()
{
Object copy = null;
try {
copy = super.clone();
}
catch( CloneNotSupportedException ex ) {
System.out.println( "oops" );
}
return copy;
}
}

 

[Lew]

Just to clarify, the following is at least syntactically correct, even
though it will in fact throw an error. But that's only because the
illustration I use doesn't actually implement Cloneable, just my own
version of it.

But it should work if you make your version extend the java.lang
version:

interface myCloneable extends Cloneable
{
     Object clone();

}

class Test implements myCloneable
{
     @Override
     public Object clone()
     {
         Object copy = null;
         try {
             copy = super.clone();
         }
         catch( CloneNotSupportedException ex ) {
             System.out.println( "oops" );
         }
         return copy;
     }

}

Untried so far.

 

[Mark Space]

But it should work if you make your version extend the java.lang
version:

> Mark Space wrote:

Yes, this worked for me. I wonder how many things would break if Sun
just redefined Cloneable to have a public method clone(). It seems an
obvious enhancement, and unlikely that many folks are (or really need to
be) implementing Cloneable classes without a public clone method.