Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.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:content-transfer-encoding;
        b=N2KYG/2/LMWX40EwVh9q0ezW/xqtJQsDbwKOL21she47dkT4hkcivOFAlmbd8yFic/
         LuvkpGDwi1WseixkVt0B5jDUdTX1W4vvdzM/WrrdN+/sknzLCY/xT7VQ7OdgYD5xWdDl
         LOH7nvR5R2Xhy0WsCOubRUnJxpXEhgVmzORKQ=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=ai-B0g0zwKbXOEH91r2i3ka5rAQ@mail.gmail.com>
References: <BANLkTimkMTitkMkJ32B32cwYc_5qpLyRhA@mail.gmail.com>
	<1305570720.1344.535.camel@guybrush>
	<BANLkTi=ai-B0g0zwKbXOEH91r2i3ka5rAQ@mail.gmail.com>
Date: Mon, 16 May 2011 15:10:00 -0400
Message-ID: <BANLkTiku0mU94nf=TOQM5GNrLAvOY9Ky4A@mail.gmail.com>
To: Andrew Curioso <andrewcurioso@gmail.com>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	smalyshev@sugarcrm.com, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: ircmaxell@gmail.com (Anthony Ferrara)

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?

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> w=
rote:
> 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 suggest=
ed
> -- 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() from =
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 are
>> > documented
>> > as having a __construct() method, yet it triggers a fatal error when y=
ou
>> 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 hav=
e
>> one.
>> > - Make sure __construct() is implemented in all SPL classes * and upda=
te
>> 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 neede=
d,
>> 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
>>
>>
>