Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66720
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A225D9BBF238624AB8DB155CC6466CCA0B56023E@VEXCHANGE10.zoo.lan>
References: <A225D9BBF238624AB8DB155CC6466CCA0B56018D@VEXCHANGE10.zoo.lan>
	<CAH-PCH7dwq9au1jkZFM5DpXQjR4JmNndbiCaz9dtWHR9tGd2Xg@mail.gmail.com>
	<A225D9BBF238624AB8DB155CC6466CCA0B56023E@VEXCHANGE10.zoo.lan>
Date: Wed, 20 Mar 2013 17:49:22 +0100
Message-ID: <CAH-PCH701DBi8LbKq=3xJWV7h09WHmr=eNKdrq7-5Z_8mzCenw@mail.gmail.com>
To: Richard Bradley <Richard.Bradley@softwire.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93404a300889c04d85e0126
Subject: Re: [PHP-DEV] E_RECOVERABLE_ERROR for "Call to a member function on a non-object"
From: tyra3l@gmail.com (Ferenc Kovacs)

--14dae93404a300889c04d85e0126
Content-Type: text/plain; charset=UTF-8

> > > 2.       Would anyone object to this change? For example on
> backwards-compatibility grounds?
> > 2, yes
>
> Could you be more specific?
> I was hoping to head off some of the objections in this email thread, or
> at least to avoid coding up a patch if it is certain to be rejected.
> Could you elaborate on what the objections might be, and what measures I
> could put in place to overcome them?
>

I can't talk for the others, but my experience on the list tells me that
this isn't an easy problem, otherwise it would be solved already, and some
of the voters are conservative when comes to changing the status quo, so
personally I would be surprised if nobody would object such a change, but
this shouldn't hold you back, the important thing is to have the majority
of the votes, you can't satisfy everybody.
your best bet is to have a clear and unbiased RFC and a nice patch.


>
> > > 3.       If I put the effort in to create the RFC and a patch, would
> it be likely to be accepted?
> > 3, depends on the patch
>
> Of course. Could you be more specific? Are there any particular issues the
> patch would need to address to be accepted? Anyone in particular I need to
> convince to get this merged in? Or should I just do my best and trust in
> the RFC voting system?
>

the latter.


>
> > > 4.       Has anyone attempted this change before and had it rejected,
> or given up?
> > 4, yes, at least there were a couple of discussions in general about
> removing/converting some of the fatals to recoverable fatals
>
> Thanks: do you have any pointers for where I can find this?
> I get no relevant hits on wiki.php.net or on the "internals" list search
> at marc.info for search terms like "E_RECOVERABLE_ERROR" or "Call to a
> member function on a non-object".
>

there were some good discussion in the
http://grokbase.com/t/php/php-internals/128335vjrj/error-handling-brainstormingthread
(see for example the reply from Nikita where he also mentioned the
cases when the fatal isn't really a fatal, just hard to recover from
sanely).
some other related discussion happened in
http://www.mail-archive.com/internals@lists.php.net/msg60652.html
and the closest thread that I can found would be
http://grokbase.com/t/php/php-internals/122nywvc5f/exceptions-for-method-on-non-object-rather-than-fatal-desired-feature

--14dae93404a300889c04d85e0126--