Path: csiph.com!feeder.erje.net!1.us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.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: Mon, 6 Jun 2016 22:56:11 +0200 Lines: 46 Message-ID: References: <1eb77568-ae31-4316-ac21-a33db79c5aa4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net tKGqebfPXcNhYYPqeEt0nAQnFl+IK+1pWrvPd1OlIH9dLcZuc= Cancel-Lock: sha1:WDWcB/5vseBUOJQjSx+D9+a77ig= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:34503 On 06.06.2016 18:06, Volker Borchert wrote: > Eric Sosman wrote: >> On 6/6/2016 8:22 AM, Eric Douglas wrote: >>> On Sunday, June 5, 2016 at 8:05:40 AM UTC-4, Eric Sosman wrote: >>>> Gosling et al. vote for Cloneable: >>>> Bloch votes against it: >>> >>> So what's the verdict, I have a class with a copy constructor, should I change it to be Cloneable? >> >> If the vote in the Electoral College is a tie, the President >> is elected by the House of Representatives. >> >> (In other words, make your own choice. For myself, I've implemented >> several classes with copy constructors and zero classes with Cloneable. >> YMMV.) > > A point for copy ctor or a factory method might be that you can > follow the old advicte to "be generous in what you accept", e.g. > have MyFancyListImpl(IMyFancyList) This whole discussion feels slightly peculiar to me because a copy constructor and clone() serve different purposes. Method clone() creates a new object of same type and equivalent state, depending on the implementation of clone() of course - but this is the intended way to go about things. So this actually creates a copy of the instance. The infamous "copy constructor" usually has a single parameter of the same type (sometimes superclass or interface) but will also happily accept any subclass instance of the argument type. If implemented with "copy" logic the best this will do is copy the state of the argument that is relevant to this class. It is not guaranteed to create a copy of the other instance. The central point of this type of object creation is that calling code is in control of the resulting object's type. Both have their merit, but different usage. There may be some overlap but when I need an exact copy, I'd go for clone() whereas when I need to control the type (e.g. as often the case with all the collection classes) I'd obviously pick a "copy" constructor. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/