Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.lang.java.programmer From: Andreas Leitgeb Subject: Re: calling own methods from constructor References: <41ac2ca5-83e8-4b80-92af-9704b373ec37@q36g2000yqn.googlegroups.com> Reply-To: avl@logic.at User-Agent: slrn/pre0.9.9-111 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: Date: 07 Apr 2011 12:32:05 GMT Lines: 50 NNTP-Posting-Host: gamma.logic.tuwien.ac.at X-Trace: 1302179525 tunews.univie.ac.at 60386 128.130.175.3 X-Complaints-To: abuse@tuwien.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2930 Robert Klemme wrote: > On 7 Apr., 10:44, Andreas Leitgeb > wrote: >> Lew wrote: >> > Andreas Leitgeb wrote: >> >>> Is there any *good* use of having the constructor call a method that >> >>> actually *can* be overridden in a subclass? I mean, are there >> >>> (non-anti)patterns of explicitly allowing subclasses to hook into >> >>> base-class's construction? >> >> > import org.apache.log4j.Logger; >> > import static org.apache.log4j.getLogger; >> > public class Foo >> > { >> >     private final Logger logger = getLogger( getClass() ); >> >   // ... >> > } >> >> I thought, I made it clear, that calling static methods was not relevant >> to my question.  So, kind of thanks for pointing out that I should have >> written non-static in the very line of the question, rather than consider >> that clear from the other (snipped by you) paragraphs of my post... > > Well, that is clear, but: getClass() isn't a static method. Because getClass() is final, it didn't occur to me, that he would have put up *that* as an example... > As for me, I can't remember having shot myself in the foot with this > feature of Java (i.e. allowing to invoke virtual methods in > constructor). I reckon, language designers figured that allowing it > is more worthwhile than preventing it. As Thomas pointed out you > would have to provide constructor arguments so subclasses can pass on > data they have created. This is tiresome and may even end up being > inefficient namely in the case where the superclass constructor needs > to decide which methods to call (or whether methods to call). You > would end up creating objects which then need to be discarded if the > super class constructor decides that he does not need them => > inefficient code. The example of that Library class-hierarchy looked a bit contrived to me. > Btw, the check would be expensive for the compiler and I am also not > sure how that byte code might look like because you need to extend the > restrictions to all methods. [...] It would be already an improvement, if direct calls to such methods from the constructor were forbidden.