Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25711 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55042 invoked by uid 1010); 14 Sep 2006 19:47:39 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 55027 invoked from network); 14 Sep 2006 19:47:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Sep 2006 19:47:39 -0000 Authentication-Results: pb1.pair.com header.from=tslettebo@broadpark.no; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=tslettebo@broadpark.no; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain broadpark.no from 80.202.4.58 cause and error) X-PHP-List-Original-Sender: tslettebo@broadpark.no X-Host-Fingerprint: 80.202.4.58 osl1smout1.broadpark.no Solaris 9 Received: from [80.202.4.58] ([80.202.4.58:53315] helo=osl1smout1.broadpark.no) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 13/2C-45066-7B1B9054 for ; Thu, 14 Sep 2006 15:47:39 -0400 Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0J5L00FJYLMD9HD0@osl1smout1.broadpark.no> for internals@lists.php.net; Thu, 14 Sep 2006 21:47:01 +0200 (CEST) Received: from pc ([80.203.129.59]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0J5L00CEFLMCAFP0@osl1sminn1.broadpark.no> for internals@lists.php.net; Thu, 14 Sep 2006 21:47:00 +0200 (CEST) Date: Thu, 14 Sep 2006 21:47:20 +0200 To: RQuadling@GoogleMail.com Cc: internals@lists.php.net Message-ID: <008501c6d836$976acbb0$9a02a8c0@pc> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook Express 6.00.2800.1807 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <0a1301c6d64f$8af01c70$a900000a@adstate.local> <00b501c6d6b4$632b7e90$9a02a8c0@pc> <10845a340609130053n395632f4ka5bbed3e49ce6ad2@mail.gmail.com> <0d4001c6d71a$fa124260$a900000a@adstate.local> <45081ABF.2020804@dealnews.com> <005301c6d768$7a5fb0e0$9a02a8c0@pc> <45087C81.3030008@dealnews.com> <006701c6d7c2$414424d0$9a02a8c0@pc> <45096A7D.3070706@dealnews.com> <003e01c6d825$92fc36b0$9a02a8c0@pc> <10845a340609141157g71bcf577ge2b9c0feefa1a961@mail.gmail.com> Subject: Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints) From: tslettebo@broadpark.no (=?UTF-8?Q?Terje_Sletteb=C3=B8?=) (This went to me privately, but in order for this to benefit the discussion, I reply to the list, as well. Besides, there's now another thread for this, too) Hi Richard. > When would the constructor be called automatically? I've used Delphi > and you use the inherit verb (or inherited - long time ago - can't > remember exactly). In PHP parent::__construct (though I think > parent::__METHOD__ would be cleaner as this removes ambiguity on the > actual name for all inherited methods). Well, let's look at C++, which I'm most familiar with. Here's an example: class Base { protected: Base(int a) { ... } }; class Derived : public Base { public: Derived() : Base(123) // Base class constructor called here { ... } } In C++, the order of construction goes from the top base class to the most derived class (although using virtual inheritance complicates that a little), and destruction happens in the reverse order. One important point is that the all the base class constructors (if any) are called before the derived class's constructor body (i.e. what's between "{" and "}") is entered. This way, you may rely on properly constructed base classes, as well as initialised member variables, in the constructor. The "Derived() : Base(123)" syntax is, as may be familiar, an "initialiser list", and may be used to initialise both any base classes, as well as member variables. With reference to another thread about uninitialised member variables: In C++, unless these are initialised using the initialiser list, they will be default-constructed, so they are also in a well-defined state, on entry to the constructor body. The same goes for any base classes. Now, what to do in PHP? As PHP is defined, the best might simply be to give an error/warning/notice, if a base class hasn't been initialised (i.e. had its constructor called) when the derived class constructor finishes. As PHP doesn't have concepts like initialiser lists, or default-construction of base classes and member variables (unless these are explicitly constructed in these lists), it may not be much point in trying to do it that way in PHP. Regards, Terje > On 14/09/06, Terje Slettebø wrote: > > > Terje Slettebø wrote: > > > > The above was a contrived example, meant to illustrate the point. What's > > so > > > > bad about it? That it doesn't check the return value? > > > > > > I am not worried about the return value of the method. I am concerned > > > that $this->something is unset yet does not throw a notice. This is > > > only true for properties of objects. Any other variable in PHP does not > > > behave this way. IMHO, PHP should either initialize that variable to a > > > default type and value or throw a notice when you try and use it without > > > setting its value. > > > > I completely agree. :) _Then_ I understood you; I thought you meant my > > example(code) was "crap"... :) > > > > Another weird thing of PHP's implementation of OO is that propagation of > > constructor calls to the base class is not ensured, something I can't for > > the life of me understand why, but that deserves its own thread... > > > > Regards, > > > > Terje