Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Are you sure, Mr. Gosling? Date: Wed, 8 Jun 2016 20:54:59 +0200 Lines: 52 Message-ID: References: <1eb77568-ae31-4316-ac21-a33db79c5aa4@googlegroups.com> <5c864ac4-9634-4c88-9d6b-d14dbf3b3886@googlegroups.com> <746532a2-c6db-4d58-afc0-1cc57440eff5@googlegroups.com> <9ecc34ba-fac1-45ed-88cb-71403c7c906d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net m+nv6ED5201sfnCux9gQuA6s4ZOU/rc1FNG8BXR10t3BnVUPE= Cancel-Lock: sha1:pVOnCybm/F08WxDgSC/vMYHfUjw= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: <9ecc34ba-fac1-45ed-88cb-71403c7c906d@googlegroups.com> Xref: csiph.com comp.lang.java.programmer:34574 On 08.06.2016 15:31, Eric Douglas wrote: > On Tuesday, June 7, 2016 at 4:30:34 PM UTC-4, Mike Amling wrote: > If both methods return the same object, my understanding is the copy > constructor just looks cleaner if you have a lot of variables you want > as default values and the clone method will copy those by default so > should look cleaner if you have a lot of variables you want copied. That does not make sense: if you want to copy state then you do not want the default values. You want the actual values from the object. Actually, cloning and copying should preserve observable state. And if you have some state that is caching something and you want the cache (say a Map) to be empty in the copy then you need to assign the member with a freshly created instance in both cases. So there is no difference in amount of assignments needed. It may even be the other way round: clone() might require less assignments if there is state in immutable objects whose references can be shared. > A copy constructor by default creates an instance of the current > class. A clone method by default creates an instance of Object, NO! Please read what is written in this thread or the documentation of clone(). > so > either the clone method of the Cloneable class must cast super.clone() > to it's own class, or everything that calls it's clone method must cast > the result. Yes and yes. Note that the API was defined before generics, that's why it is the way it is. > Defaults from clone() to consider (if we don't want these, we either > need to specify the alternative in the copy constructor, or replace in > the clone method on the new instance returned from super.clone()): > Immutable objects get copied by value, bucket objects get copied by > reference. This is wrong. Objects ("reference types") are copied by reference by Object.clone() - regardless of whether they are mutable or not. Only primitive types are copied by value. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/