Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52440
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=drYlweVXnhwldPvdOzapcyErye/xo/BNFFtH+voUzCaG5M81QfrsDXKf7wBG0CqBqf
         5Pz042owQKOhycTVNOn5bI5g64GlR1ApBImyml08CAC9JRz4oydh1dzpO6YBdp11eDrx
         1Ow8gC6lMgRfKPSRdOpIaawisL7xG8+lljMBg=
MIME-Version: 1.0
In-Reply-To: <BANLkTiku0mU94nf=TOQM5GNrLAvOY9Ky4A@mail.gmail.com>
References: <BANLkTimkMTitkMkJ32B32cwYc_5qpLyRhA@mail.gmail.com>
	<1305570720.1344.535.camel@guybrush>
	<BANLkTi=ai-B0g0zwKbXOEH91r2i3ka5rAQ@mail.gmail.com>
	<BANLkTiku0mU94nf=TOQM5GNrLAvOY9Ky4A@mail.gmail.com>
Date: Tue, 17 May 2011 14:49:58 -0300
Message-ID: <BANLkTim=dqwPbB-vpCs8zEaHQkbvW7dCUg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Andrew Curioso <andrewcurioso@gmail.com>, =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	smalyshev@sugarcrm.com, internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e64ec5328c9f3f04a37c66c6
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: martinscotta@gmail.com (Martin Scotta)

--0016e64ec5328c9f3f04a37c66c6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

 Martin Scotta


On Mon, May 16, 2011 at 4:10 PM, Anthony Ferrara <ircmaxell@gmail.com>wrote=
:

> Personally, I really don't care for something like this.  Would it be
> caught by a __call declaration if one existed (since it is a call to
> an undefined method)?  Would you expect it to?
>

Although current PHP implementation treat them as method, it's important to
note that constructors are not methods.

$a =3D new Foo ();
$a->__construct(); // encapsulation broken


> I'd rather see calls to non-existent methods generate a catachable
> fatal error (rather than a hard fatal error that's currently thrown).
> That way we can use an error exception to "catch" the fatal and
> recover from it if necessary.
>
> But silently ignoring a called function, something just doesn't sit
> right about that...
>
>
>
> On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso <andrewcurioso@gmail.com>
> wrote:
> > I like that idea and I like that it works for userland classes as well.
> >
> > +1
> >
> > Do you think it should throw a warning, notice, or -- as you both
> suggested
> > -- just silently succeed?
> >
> >
> >
> >
> > 2011/5/16 Johannes Schl=FCter <johannes@schlueters.de>
> >
> >> Hi,
> >>
> >> I|d actuallz suggest a different option:
> >>
> >> If a parent constructor is called but doesn't exist the engine should
> >> ignore this. The same goes for destructors.
> >>
> >> This solution would also work for userland classes.
> >>
> >> johannes
> >>
> >> On Mon, 2011-05-16 at 14:14 -0400, Andrew Curioso wrote:
> >> > So, I ran across bug #54631
> >> >
> >> > A fatal error is thrown if you try to call parent::__construct() fro=
m
> a
> >> > subclass
> >> > of SplObjectStorage.
> >> >
> >> > I was going to close it as "expected behavior" since that is pretty
> >> normal
> >> > if the parent class doesn't implement __construct().
> >> > Also, the docs don't list it as having a __construct() method.
> >> >
> >> > But then look at SplDoublyLinkedList (and a bunch of others). They a=
re
> >> > documented
> >> > as having a __construct() method, yet it triggers a fatal error when
> you
> >> try
> >> > to call
> >> > "parent::__construct()" from a subclass' constructor .
> >> >
> >> > So it seems to me that there are two possible solutions:
> >> >
> >> > - Update the docs to remove ::__construct() for classes that don't
> have
> >> one.
> >> > - Make sure __construct() is implemented in all SPL classes * and
> update
> >> the
> >> > docs.
> >> >
> >> > * Even if it is empty.
> >> >
> >> > What's everyone thinking?
> >> >
> >> > I'd be more than happy to add the constructors to the code where
> needed,
> >> I
> >> > just
> >> > want to make sure that it is the right move first.
> >> >
> >> >
> >> > - Andrew
> >>
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e64ec5328c9f3f04a37c66c6--